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.
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.