- it has interest: you're paying extra in maintenance, debugging and manual testing for all the shortcuts you've taken
- it can be paid back by refactoring the bad module. The price of such a refactoring is usually known and, unlike in short sale, won't get to infinity
- it can be used to grow. Instead of working five years on a perfect solution we build something plausible right now and then keep refining it
Take, for example, something like Mozilla's Facebook Container extension [1]. It's fine if they take some shortcuts that allows them to launch that faster if it turns out there's another Facebook scandal in the news - launching faster allows riding the waves of publicity, resulting in more users. Even though the total development effort is more when they have to clean up those shortcuts after launch, the additional effort has been used to grow.
[1] https://addons.mozilla.org/en-GB/firefox/addon/facebook-cont...
I see examples of the latter all the time in the experience of developers and how they approach decisions. I have recently worked on largish (or at least in the 10s of millions of dollars of investment to create) codebases in which developers (recently - like 2013) wrote switch statements that became God classes because they simply were not familiar (at least not in practice) with patterns that avoided it. Consider that one example and imagine the type of havoc that lack of experience creates across the entire codebase. You can say this is a case of ignorance, which it is, but it's the same as the ignorance of some to handle money in a sustainable way. It's like giving a credit card to a kid.
As I see it, tech debt isn't enough of a descriptor of the kind of engineering shortfall one is experiencing. To understand precisely what one's talking about one needs to characterise the problem more.
My main problem is that the blanket term for the issue uses a best case analogy, when the worst case is so much worse; it's not funny.