Perhaps not, but there're plenty of times you realise the "proper" solution that's going to leave you with well-structured code that's easy to maintain and easy to extend to likely future functionality is going to take weeks, whereas a quick'n'dirty solution that will get a bug fixed or an MVP-version of a feature implemented could be done in a few hours, and the latter option makes sense even from a technical POV because there's little certainty that the extra effort will pay off (esp. if it involves higher risk of breaking existing functionality, which is often the case). Unfortunately it's the accumulation of such decisions and lack of time to go back and revise decisions/rewrite code that lead to unwieldy and bug-ridden codebases.
If management is using it usually an attempt to shut discussion down in the context of (i) poor psychological safety on the part of devs because (ii) management doesn't trust anything the devs say because (iii) management knows that the devs are reading cargo-cult blog posts like "if this software was written in Haskell it wouldn't have any bugs".
We need to launch so we will do this now. We know January is going to be quiet so we plan to fix it then.
Taking it on unnecessarily is bad for the health of the business and worse than financial debt because technical debt, unlike financial debt, is not fungible.
We SPEND 2 hours today to possibly save 3 hours in a few years.
We SPEND 2 hours today to possibly save 3 hours in a few years.
We SPEND 2 hours today to possibly save 3 hours in a few years.
We SPEND 2 hours today to possibly save 3 hours in a few years.
We SPEND 2 hours today to possibly save 3 hours in a few years.
Oops, we just found a better way and all the code is gone.
If you take on debt the bank is going to question if you can pay it. You're going to have to go through a formal process and bring in expensive experts such as accountants to justify that taking on debt is worthwhile.
Most "technical debt" is blundered into out of ignorance. Nobody sits down and thinks "we can save two hours now at the cost of three hours later" because it would probably take four hours to do the calculation. Sometimes it really is like that but frequently it is like "we can save two hours now at the cost of of two months later", such as when people make an incorrect database design that involves cleaning up corrupt data later on. Cases like that dominate the cost of "technical debt" to the point where the 2 hours now, 3 hours later cases just don't matter.