I feel like this post misses the point of the whole "technical debt" analogy. They way the author talks, it seams like their org. uses it as a catch-all term for complaining about the code base. But that's never been the point of the term.

"Technical debt" is the justification for process and development decisions that require more time up-front but will save time in the long run (especially as a term to communicate this to non-technical management). It only comes into play when you're talking relatively about two or more different choices.

Just as an example: when deciding to move ahead with less testing or to move more slowly and write unit tests for every function, you should consider the first to come with more technical debt. That doesn't mean it's the wrong decision, it just means that it should be a factor in your thought process.