It seems to me that whether the distinction this article makes is necessary depends on what angle you view the situation from. When looking at how you introduc

It seems to me that whether the distinction this article makes is necessary depends on what angle you view the situation from. When looking at how you introduce technical debt, it matters a lot. The kind of technical debt Cunningham talks about is inevitable with any kind of iterative development. In contrast, the shortcuts, hacks and mistakes that normally get called technical debt can be minimized by taking some time up-front. But from the perspective of paying down technical debt, I'm not sure it matters as much. The code has features that will continue to slowly cost you time and energy until you fix them. It doesn't matter why they were introduced. The author's point that Cunningham's form of technical debt won't appear in any kind of static analysis is still a nice observation.