I mean a lot of what you said applies but that doesn't make the entire concept BS.
On the one side of the coin you're right, it doesn't matter for a huge percentage of startups - until it does, and then it can matter quite a lot, very quickly.
Yes most startups fail so technical debt isn't a primary concern. But on the flipside if a startup becomes successful they'll have the budget and experience to clean up technical debt. Only at that point it's like repairing a car while the engine is running - when you're scaling fast, suddenly you have millions of new users flooding in, you can't take your systems offline and rebuild them on the fly - users demanding new features and improvements takes priority over fixing invisible stuff they can't see, etc. I'm sure you understand this.
I can think of a few companies who were big players in our local / national sphere who hit it off, got splashed all over as the next big thing, and their systems totally failed during their big events, or were seen as industry leaders only for a breach to sink them overnight.
I see part of the problem is technical debt often only gets raised retrospectively, when it would take huge efforts and expense to deal with. It doesn't take an insane order of magnitude of time to move a little slower and make more calculated decisions to build something with scalability and longevity in mind. A sensible balance should be struck between velocity and engineering. Technical debt should be raised early in the process and used proactively in decision making.
I suppose it doesn't matter if you're an investor or owner just trying to get ahead of the market and sell it off for profit, you can flip Gartner-as-a-Service products all year long and still come out ahead even if a good portion of them fall over their own feet at some point in the future.