The term "technical debt" has always rubbed me the wrong way.
Most technical decisions were sound... at the time!
I agree, people from 1999 didn't predict what would be happening in 2019. But why is that considered to be some sort of debt?
Often, teams cut corners to release a feature earlier/on time, and only make it work for the MVP use case without restructuring the codebase to fully accommodate the change. In this setting the term debt is pretty fitting.
In many modern web companies a given project has a useful life of ~3-5 years, if its still running by year 8 with a team that's been on KTLO a few things are probably true.
A: No one knows how to productively add features.
B: The business need for the project was much larger than the KTLO funding would imply.
Odds are at this point there are a long list of user complaints, year+ old feature requests, and excuses being made to the board for why some initiative is facing yet another delay.
Perhaps we should be talking about software depreciation rather than tech debt?
Many tech debt traps start with relying on an LTS version of OS or libraries. The philosophy behin that is, that software behaves like a chair: You buy it once, and then you sit can sit on it until it is no longer needed.
A much better analogy is a horse: You need to feed and take care of it daily, and you need to be ready for it do die when you still need it.
No one knows how to run and manage these systems, yet we do it all the time!