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.