This is really wishful thinking about the nature of technical debt. Most technical debt is completely unnecessary and is due, entirely, to lack of planning and organization (in other words, operations problems). In a nice tidy perfect startup world your comment might make sense but that's such a small fraction of software businesses that no meaningful conclusion should be drawn from them.
This is analogous to saying no business needs financial debt, and can bootstrap entirely out of cashflow. It's baloney. There are many situations where you can do quick-and-dirty versus (slow) elegant-and-enduring, and there exist business (note I said, business, not technical) situations where the former is better than the latter.
The problem with the analogy of technical debt vs. real debt is that technical debt is the actual product itself. You aren't building a house using mortgage, you're building a house with shoddy materials and hoping you can flip it before it falls down on you.
I don't completely disagree with you at all -- there is a lot to building marketshare and having the dominant position. But I think you are way overselling it as an advantage. Being out in front and having the whole thing collapse on you is way worse than a slow start.
But again I think this conscious idea of doing quick & dirty is less prevalent than the debt caused by lack of experience and poor operations.
> This is analogous to saying no business needs financial debt, and can bootstrap entirely out of cashflow.
Technical debt isn't a commodity. You can't generally can't infuse legacy technology with more technology and fix things. At best there's a lot of bespoke work to get the legacy system to work with the new technology.
