The problem with the "debt" terminology is that debt is actually fairly predictable and easy to manage. But bad code tends to have very volatile effects–often the cost of working with it is 0, and sometimes it's enormous. "Unexploded Land Mines" might be a better analogy.
Debt is predictable, but perhaps not the ability to pay. My company may know how much it has to pay each month for the next 20 years, but it won't know the financial conditions then.
I find the hard quantification part is explaining it to non-technical executives. Saying "You can't have feature X because of long term investment Y" is very hard. The one thing I've seen work is telling engineering "You can use 25% of your time and resources to pay this back"
The key thing about technical debt is quantifying its interest rate. If you tell an executive "I have a method for the business to take out a huge loan, expedite time to market, and has no observable interest rate", of course they'd take it.
Declaring technical debt bankruptcy and requesting a do-over is rarely persuasive, particularly for a profitable service or product. If proponents of technical debt want to win these corner office debates, they need to start developing quantitative models for predicting the size of the debt, and the interest rates. And it may well be impossible, because it's not clear cut that the next design will actually be better. I've seen simple user account management shell scripts replaced with piles of error prone Java, requiring a large set of new DAOs for every new integration.
There's a good chance that the do-over will be subject to "second-system syndrome": All the unicorns and rainbows that were put into the backlog suddenly become part of your MVP.
