I'd agree with this, but this is orthogonal to tech debt IMO. Tech debt is a trade-off of a simpler / less extensible implementation in exchange for faster product / business validation of experimental (in some sense) code. It doesn't matter how fast the individual developer is: all that matters is that, where T is some arbitrary unit of execution speed, the simple solution takes e.g. 1T and the more future-proofed solution takes 2T or 3T.

Like I said here -> https://news.ycombinator.com/item?id=30286860, I think this whole thread is proving slightly unproductive because everyone has their own definition, and concrete example, of tech debt in mind - and so we're all talking at cross purposes about different things.

I suspect that lots of the stuff people seem to implicitly be talking about is not tech debt by my definition, but rather just shoddy code. That seems to be what your comment is talking about. If you can write a better implementation in the same time (subtracting time taken to learn about either implementation technique) then it's not tech debt AFAICS.