But sure, it'll be different this time.

If you can code something quickly and well enough that it doesn't immediately collapse under its own weight, you have succeeded. The fact that a codebase has existed long enough to become "legacy" means it did a good enough job to stay alive.

I don't think that's fair to a large number of engineers. We know that code gets loaded with technical debt and we know that we can't spend time fixing it because of "business realities". That doesn't mean it isn't a problem for us though. Anyone whose had to maintain a codebase that's years old and riddled with undocumented and untested "features" suffers for it. Old code is a source of stress and anxiety. It might make money, but that isn't a reason to think it's not an issue.

Far from. The worry is not "this code is old." Plenty of old code (especially boring old code) is cranking along just fine.

The worry is that if an old, abstruse system stops working or has a critical security bug, there's a real risk that nobody will be able to put the fire out.

Well, yeah, for the first version. But when is the first version also the last one? Not in many good situations. Crap that doesn't immediately collapse under its own weight will probably immediately collapse as soon as you add more weight to it in version 2.

A lack of anxiety about the structure of the product is myopic and ignorant of engineering realities. There's got to be a balance. Too little anxiety, and you lose customers to competitors that spent more time to build a quality product, structured so that it's easier to grow. Too much anxiety, and you're in a "perfect is the enemy of good" situation, and you'll lose customers to competitors that were able to iterate faster and with a proper balance.

But you won't. Even if you want to, the client won't pay you to because all the client sees a working solution, so you never get the chance to.

That's the problem the author is highlighting.

Code "quality" (whatever bullshit metric you use for that) is not the only metric of improvement. In fact, it's probably the least important metric to optimize over time.

Usually that's new features and bug fixes. It's very rare to find a client who'll happily pay for refactoring. If you're in a job where you get time for that you should consider yourself very lucky indeed.

EDIT: For what it's worth, I agree with your point about code quality. What's 'beautiful' now is only 'perfect' in the frame of the current feature set. It might be horrible if the next feature that comes along changes things dramatically. I'm very much of the opinion that "good is better than perfect", just with the addendum that the code at least has to be good. Bad code is just bad.