Expanding slightly on the article, there are at least a few places where incremental refactoring is (often) beneficial:

(1) Before you work on a feature, if the existing code has some tradeoffs or outright deficiencies which make the new feature hard to add, start by fixing the work site, and then add the feature. The benefits from this snowball quickly on code of any age or complexity, and since the assumption is that we're only doing "extra" work when a feature was going to be complicated and that the "extra" work makes the feature simple, it doesn't actually add a meaningful amount of time to your tickets (i.e., throughput slows down a bit at the beginning but not enough for management to notice or care, and it ramps up over time).

(2) A fair number of developers seem to "think" in code -- incrementally building out the solution in code to learn how to solve it and build appropriate mental models. If this describes you, throw away the first draft and start over. V2 takes a fraction of the time to write as V1 since you now know what you're doing, and the second draft will be substantially better. If this gets pushback, never describe V1 as "working" or a "prototype" or anything vaguely implying that enough duct tape and unpaid overtime would allow it to hobble along in production. I find that "brainstorming" often elicits the correct response.

(3) The article calls out that after building a feature "correctly" it might not fit perfectly into the existing code. I'm not necessarily convinced that the right time to refactor this is immediately (since it's so hard to predict which abstractions you might need (ignoring rules of thumb like "separating payments and entitlements", which represent hard-won tribal knowledge)), but if you're able to come up with a measurably better solution then the best time to implement it is definitely while everything is fresh in your mind and before you bug your coworkers for a review.

(4) The article _also_ calls out that cruft has probably accumulated over time, which might need to be handled incrementally or with a rewrite. A lot of that is often addressable via (1), but partial rewrites _can_ be cheaper than you think. If you happen to notice a particularly thorny problem afflicting an organization, can confine it to under a few thousand lines of code, and have a decent idea for how you will make it better, spending a couple days to rip it out is time well spent. I've worked on a lot bigger projects before than those sorts of quick rewrites, but those small changes have had a comparatively outsized ROI. They're fast projects that nobody else had any good ideas for fixing (or they would have done so rather than bitch about how much of a hassle the thing is) that can immediately save 1+ developer days per calendar day or 10 GPU years per calendar day or whatever. Your work pays for itself quickly, and since it only took a small fraction of your time you still have nearly identical throughput on whatever your main job is.

(4a) No longer job-related, but a similar idea manifests itself in ordinary household functions as well. If you have a low-risk, low-cost method for achieving 10%+ annual returns, that's often worth considering. Consider buying flour or soap or something in greater quantities than normal. It's not uncommon to pay 2x the price for 5x the quantity. If you go through the item every 2.4 months (illustrative, to make the rest of the math easy), consider the relative effects on your wallet from buying in bulk. You spent 2p (for some unit price p) immediately (and couldn't invest it or do anything else; it's gone), but at the end of the year you have 3p more cash than you would have had you bought smaller units. I.e., your 2p investment grew 50% to 3p. That's an amazing annual return that you couldn't easily replicate elsewhere, even after accounting for tax-deferred benefits or other such effects. Similarly, paying some portion off a 20% interest loan (try to never get those...) has, ignoring taxes and bankruptcy and other such details, exactly the same effect on your net worth as getting 20% returns in some investment account. Moreover, it's nearly "risk-free", whereas such a high yield investment account would not be.

(4b) Individual circumstances vary. Try to interpret (4a) in a charitable light; if you don't bake much, don't buy 10yrs worth of flour. If you have to buy extra square footage to plan to buy in bulk that's maybe a problem. If you require a ton of time to avoid scams or quasi-scams (like stores pricing bulk items with a higher per-unit cost than non-bulk items) then that's potentially a cost that keeps it from being worth it. The point though is that on the scale of a single person going through a single life, there are lots of small things you can do which have outsized returns (education and learning fall into that as well IMO, but this comment is long enough), far beyond the strategies which work at the scale of a retirement fund.