Cunningham makes a convincing case for the teerm:
He even calls out that some teams think they don't have to pay back the debt. I think that is the norm, and that's the problem of debt. When financial people use debt, that debt comes with structure and consequence: it might be monthly payments or it might be due sometime in the future. Offer such people a "debt" that has nobody enforcing it, nobody quantifying it and of course it wont be paid back.
Agile engineers making scary "booga booga" noises about "we need to refactor" just don't carry the same weight as not being able to make payroll because your note is due. And yet that seems surprising to engineers.
Incorrect. He notes that debt (finanial or technical) is useful in getting things done more quickly, but must be repaid.
Technical debt enables getting a minimal product or prototype out to gain experience and further refine design. It is specifically contrasted with bad software. Deficiencies are to be addressed later. And yes you're correct in that this last step is often omitted.
However, if the conversation is one of "debt", then, in my experience, the necessary work is not done later, because there is no organization demanding repayment.