The idea of Technical Debt, though prevalent, is fallacious, because implicit in the idea is the belief that time-to-delivery is somehow _necessarily_ a function of code quality.
But this is not true. Here's why:
The first thing to realize is that code quality is an objective quality; it is the degree to which your code is decoupled, the narrowness of the interfaces between components and the relative size of each component. (This is objective because you can take two systems that deliver the exact same business function and compare them wrt their degree of coupling, cohesion, and interface width.) The first fallacy is to think that code quality is somehow subjective; it is not: not at least not for the sense of code quality that matters--which is how much _necessary_ business cost there is to evolve the code. (Note that _necessary_ is the key word; obviously it will always cost an inexperienced/novice a lot of time to contend with a code base regardless of its structural qualities.)
Another thing that gets conflated when talking about Technical Debt is the "flexibility" or generality of the system that is built. It is a mistake to consider a specific (ie, non-generalized) system as having higher technical debt. That would be like saying Gmail has high technical debt because it doesn't have Kanban features. A high-quality systems (low technical debt, so to speak) can be a system that is quite specific, quite hard-coded, etc.
These are two fallacies. Now that they have been called out, the last thing to consider is whether or not there is some _necessary_ cost savings in delivering a system with "higher debt" (ie, a system with more complexity).
As an experienced practitioner who has worked with many other experienced practitioners in large and small companies alike, I can say confidently that one's ability to deliver a simple system is a function of skill set not time. In other words, a skilled practitioner will take a no extra time to deliver a simple system albeit perhaps a specific one. There is a necessary time trade off if we are talking about making a system with more generalized capabilities--but at this point we are talking about features and priority and managing feature creep and the like.
This is where I think many startups fail when they think that 5 mid-to-junior engineers are better than 1 qualified* senior. The only caveat is that there are many (and, perhaps, most) "seniors" out there who have a not all cultivated the relevant skill set. Who have spent their careers leaning on this false notion of Technical Debt and the idea that "I simply didn't have the time to make a good system"--in this line of thinking, there will be no growth because implicit in it is the idea that there really is nothing new, no now skill set, to learn, that all there is just a shortage of time.
A tennis player would never think, "I would played a better game had I had more time." As if somehow there is a world in which tennis could be played in slow motion. No: the tennis player practices and practices until her muscle memory is tuned to play a competitive game in real time.
Likewise, a developer must _specifically_ train herself to play a good game in real time. So that the ability to deliver quality is part of their muscle memory. At that point it is actually harder -- takes longer! -- for this developer to build a complex system. Decoupling becomes instinct. Much like a skilled tennis player would have to go out of their way to play badly, with bad form, etc.
Unfortunately I don't see this training happening in either academia or in the practitioner's world. Everything is too optimized for immediate delivery and so people spend their careers learning how to hack it through and then only _after the fact_ come up with this idea that Technical Debt is somehow a necessary thing. The idea of Technical Debt is alluring because it is much easier to lean on than the idea that you have a serious lacuna in your skill set.
Now one might say I'm not being convincing because you still have to take the time to "learn" the skill set. This is true. But this is not change the above reasoning at all. Unless one thinks that learning and delivering can happen together in some optimal fashion. I don't believe that they can. I do not want the person building my home to be learning on the job, that is for sure.