Cost of change

Inevitably, one day, this 'bad' solution will have to be changed as by Lehman's laws of software evolution. By that time, you will need to pay the extra cost (or interest, as by metaphor) that you did not pay for when you made the 'bad' decision in the past.

These laws of software evolution do not differentiate between 'good' or 'bad' decisions. Software needs to change to stay current. Period. It seems it does not matter whether you chose the 'right' or 'wrong' solution. Does it cost more to change a 'bad' design than it costs to change a 'good' design? Maybe.

A problem with quantifying your technical debt is that the absolute cost of the 'good' design is not known, because,... well... you did not choose that design. Additionally, the 'interest' will change over time, because of changes in the value of money, salaries, and the value of the solution. So, it depends both on what was considered the 'good' design and the very moment you're about to change that 'bad' design.

Maybe even the 'good design' back then, is not the same 'good design' you would go for now, because, you know... times have changed (evolution!). Can you even relate the debt of the 'bad solution' from way back when to the interest you need to pay now for that new, 'good' solution you want to implement? If not, what are we talking about? Let's assume you can. Why?... because both designs solve the same initial problem.

Ironically, it appears that money is a bad quantifier for technical debt. So, what actually is a good unit for measuring technical debt? Man-hours? Lines of code? The answer is (as always): it depends. This time it depends on the skills and knowledge level of your team members, on the programming language, and more like this.

'Good' vs 'Bad' design

Let's take a step back; if technical debt arises solely from the deliberate choice of the 'bad' design instead of the 'good' design, with the assumption that every 'bad' design is harder to change (hence, more expensive) than a 'good' design, then what defines a 'good' or 'bad' design? How can we measure this?

In general, 'good' design has some characteristics on the code level: low complexity, low duplications, low coupling, high cohesion, high test coverage, split into modules, and such. Analogously, a 'bad' design will then have high complexity, high duplications, high coupling, low cohesion, low test coverage, and (very) few modules. Many of these metrics can be measured, even automatically (e.g., Sonar).

Does measuring technical debt matter?

Having the metrics (complexity, duplication, test coverage, etc.) will help you find design flaws in the code, but it does not tell you whether this code, which is part of a bigger design, is like this on purpose. The intent is lost. It seems that measuring technical debt, as defined as deliberately choosing the 'bad' design, cannot be measured automatically.

So, does it matter to differentiate between technical debt and other design flaws? As a developer, you'll have to deal with the non-technical debt defects as well at some point. And aren't they just as painful to change as the deliberately chosen bad designs (at scale, of course)?

Conclusion

At the moment your team needs to redesign, refactor, or just maintain existing code, it does not really matter if any extra work (or costs) resulting from 'bad' design is coming from technical debt or other design flaws. They will have to deal with it either way.

The question whether a piece of code is in fact technical debt or not is the wrong question. The question to ask the team is: should we fix this crap now?

Gain insights

It is a good idea to record the deliberate choice of the 'bad' design. Make documenting design decisions a part of the design process. This, in general, is a good way to document designs; not just for technical debt, but for any design decision. As team members come and go, and software evolves, it is a good thing to be able to revise decisions made in the past and see why they were made to judge whether they're still appropriate. Basic information such as the problem it solves, the solution, and the arguments why are the most important. Sure, you don't document every design, just the key ones or the ones that are hard to change.

Technical debt is a term that shouldn't be used within development teams, as it is irrelevant to the development team members (just fix it now or later). You could use the term to explain to management at design time that taking that shortcut now will indeed shorten time-to-market, but will inevitable give problems (in terms of extra work) in the future.