In my experience technical debt almost always comes from management's misconception that:
(a) A product that works now will always continue to work, even after you accumulate 10X the number of users.
(b) Adding new features only involves adding code, not rewriting stuff that already works.
(c) For a product A, delivering milestone A1 by deadline A1 is independent of delivering A2 by deadline A2. In reality the existence of A2 affects the timeline and architecture decisions of A1.
All of these are rampant massive fallacies in technical management.
Most startups can expect to either A) have a lower cost of capital in the future, or B) to fail.
This means opportunity cost is ridiculous, and expedience often can be worth a whole lot of future wasted resources and decreased velocity. Survive to tomorrow, where you have more resources and can pivot to doing things in a cleaner way.
So it's not completely stupid to pretend A & B are true. You can pick up velocity now, in exchange for future problems. And as long as the interest payments aren't too high it's well worth it.
Confession: As a developer I've personally fallen for all three of those misconceptions, and I will probably keep falling for them.
I'm also pretty bad at actually knowing when I'm running the "technical debt credit card" or even checking what's left in the balance to pay off. Sometimes when I'm trying to pay down the balance, I end up adding a lot more to it. What I understand well enough, I then have a hard time communicating effectively.
I'm a pretty bad influence, so when I end up spending a lot of time working with any other developers I eventually catch them doing the same thing. Some more than others. What's worse is that we are the only ones who could possibly know anything about the technical debt that we understand so fuzzily.
All that management can hope to get is a secondhand account of all this, so I tend to award mine only partial blame for being pretty consistently terrible at making technical debt decisions.
(a) A product that works now will always continue to work, even after you accumulate 10X the number of users.
(b) Adding new features only involves adding code, not rewriting stuff that already works.
(c) For a product A, delivering milestone A1 by deadline A1 is independent of delivering A2 by deadline A2. In reality the existence of A2 affects the timeline and architecture decisions of A1.
All of these are rampant massive fallacies in technical management.