Technical debt it the intentional decisions you make to go faster. You can pay it off or not if you want to.
Unfortunately every project I have been on has very little of this. The real problem I see are not intentional decisions, but "If only I had known". The team that choose a framework and 3/4ths the way though the framework company dropped the product (I know a product shipping on WinCE 6 - MS dropped support for that on them 1 week before code freeze). The team that started on some new fad that seemed good only to be the first to find the issues when used in their situation (the fad is overall good, but the limits are not understood).
I've come to the sad conclusion that excessive code quality is a smell. And most attempts to head off technical debt are really just premature optimization, which is its own sort of evil.
These are the justifications that lead to Technical Debt.
Unless you write a self destruct system that prevents the software from starting after a certain date... there is no such thing as 'good debt'.
Projects come from POCs, they get moved into Production and are never replaced, just patched.