I like the reasoning, but disagree with this passage:

The “pile of technical debt” is essentially a pile of knowledge – everything we now think is bad about the code represents what we’ve learned about how to do software better. The gap between what it is and what it should be is the gap between what we used to know and what we now know.

The knowledge of “how to do things better” can already be known before the code is written and it would still make sense to me to talk about “technical debt” when the choice is made to write/ship “substandard” code. There is new knowledge to be gained in these cases, but it’s the knowledge of “we can get away with substandard code for this product feature because it never gets used enough to matter”. Or even “the client who asked for the feature realized it’s not what they need”.

I don’t like how the author seems to conflate technical knowledge with client/market knowledge. I don’t think it’s categorically wrong, per se, just too unwieldy to be useful. Similar to how, with enough linguistic and reasoning gymnastics, anything can be “research” — or how in programming anything can be rewritten into a “pure function”.