Technical debt is intentional compromises. It sounds like you are thinking of not intentional compromises, but instead accidents where someone didn't understand the requirements and so did it slightly wrong for the expected future. Cases where the system wasn't designed to handle requirements changing in the way they did so you had to "make an ugly hack" to ship are technical debt.
Calling it intentional makes it sound reasonable, but the thinking could be "I ain't gonna be around when it breaks".
I understand the distinction, but at some point it's not super helpful, and I would argue even counter productive.
If you have a system that is big enough and has had enough change over time that it's structure is no longer well suited to the current or near future job-to-be-done, then it doesn't really matter how you got there, you need to explain to non-technical stakeholders that current business requests will take longer than it would intuitively take to build if you just look at the delta of the UX that exists today compared to what they want (ie. the "why can't you just..." conversation). This is a situation where the phrase "technical debt" is a useful metaphor that has crossed the chasm to non-technical business leaders, and can be useful (when used judiciously of course).
It actually undermines the usefulness of the metaphor if you try to pedantically uphold the distinction that tech debt is always intentional, because non-technical stakeholders will wonder why engineering would intentionally put us in this situation. I understand we all get to have our techie pet peeves (hacker != black hat), but this is really not a semantic battle I would fight if I'm dealing with anyone non-technical.