I have never really like the concept of technical debt. It sort of implies all imperfection is debt. Yes all software has imperfections and warts. And as this article explains it's not really debt, as it often doesn't need to be "repaid".
I put it in the same bag as things like TDD - stuff that is promoted as being "basic truths" but are really of very questionable and suspect validity.
The term "technical debt" has entered the standard lexicon of programming and software project development and has often been called out for being an incorrect metaphor. Yet it persists as a way to talk about the decisions made during software engineering. I believe it is over-used and often makes technical conversations more confusing.