Messy code is painful so the answer is sought, when we don't have much experience, in what we learned in classes and books: elegant abstractions. But we end up abstracting business logic in such a way that when the business needs to change, our code can't change with it, and that's when we have true tech debt of the "let's rewrite the world!" sort. It might be beautifully designed abstraction, but if it's tied to the features of yesterday too much, it's going to become increasingly brittle and painful.
Now when someone says "we can ship this sooner but it'll be hacky and introduce tech debt to make the code re-usable" I'm much happier, and would rather have the code not be intended to be re-used until we prove that we understand how we'll want to use it next time.
What unfortunately happens a lot is orgs taking on tech debt without realizing it (devs are too junior, or management doesn't listen to devs, or various other reasons). Then 1-2 years later, the system is falling apart and the old engineers are gone. The new ones just call it tech debt as this kind of unavoidable force of nature that was dropped on them (because it kind of was).
Or worse, the devs of old ARE still there, but pretend that after 1-2 years, its inevitable for a system to be falling apart and needing to be rewritten from scratch.
This level of industry immaturity prevents the tech debt concept from fully working.
In organization where tech debt IS a fully thought out and planned out compromise to get value today at some cost to be paid off later, then yeah, it not only works: it's often the right thing to do.