No, this is still a payment against technical debt. From the top of Martin Fowler's article:

"The extra effort that it takes to add new features is the interest paid on the debt."

If adding a new feature starts with, "just throw out all the code and start from scratch", that's a much larger cost over the long term than building code that's easier to maintain and refresh.

With very few exceptions code that is "easy to maintain and refresh" over any appreciable time horizon (say,longer than 2-3 years) requires the kind of engineering effort that the modern world of "CS trivia is good interview material" generally derides. I'm not even talking about "real" engineering processes as might be used for space systems or whatever; I mean just basic requirements analysis and technical documentation.

The cost of rewrite at that point is typically less than cost of straightjacketing the existing codebase to support all new requirements, otherwise it is less likely to happen. So, defaulting it is.

(Mind you I'm not fully sold myself that 'technical debt' is a useful analogy at all)

Not necessarily. More like an asset that has finished it's designed lifespan and the org has moved to a new asset.

That begs the question, what distinguishes actual technical debt from short-lived assets?

You can't fully make that distinction until it happens.

Sometimes you can say "I know this will need to be rewritten later" and be pretty sure you're seeing technical debt be accrued.

But other times you have no idea. It might be a tool that was intended to be used for a few weeks, but turned out to be incredibly useful and lasted years. Had you known, you might have written it better if the first place.

Technical debt isn't like financial debt in that there's nobody with an accounts sheet telling you that you owe them anything from the start. You don't necessarily make a deal with anyone. So you can't judge its existence in the same way.

Schrodinger cat's technical debt.

Or the target's moving fast enough that it's inefficient to build a gold-plated solution when a quick hack will get you out of trouble for now.

Research code is much the same. Your code doesn't have to be great (or even OK, to be honest) as long as it runs well enough to provide the results you need for your paper.

A technology no longer being supported (e.g. Flash, Silverlight, IE) is not technical debt though, it's external influences.

Likewise, rewriting a front-end in the framework of the week doesn't have to be because of technical debt; Angular 1.x was fine and it's still fine, however you'll see a lot of upgrade or rewrite projects happening right now not because of tech debt, but because people simply don't want to work in Angular 1.x anymore, or an employer can't find competent people that want to work with it anymore.

Likewise, COBOL applications aren't bad because of technical debt per sè, it's just become very hard to find people that can maintain it.

Never really seen that in practice, code is "touched" but rewritten?