I agree with what your saying, but the important idea with Technical debt is it's the interest rate and payments that you really need to consider not the capital.
A lot of terrible UI code may be acceptable as it rarely infects the rest of the system where a smaller design bug in a tiny utility library may end up causing worlds of pain even if it's rather elegant code that could be reused on other projects just fine.
Apologies for a rather late response on this one. I think the "technical debt" view of this would more be that it makes sense to rely heavily on some third party libraries and frameworks to organize and execute your UI.
You are taking out a debt against their knowledge in getting your application off the ground. This directly so if it has to be licensed, but equally true for free frameworks.
My argument is that for many people this will never be a problem. Consider how many games farm out the heavy graphics coding to libraries.
For many software companies and content producers, the content that you are producing is the value they bring. Trying to morph the actual value of a company into a new way of doing this is risky.
Which brings me to a comment I made in another subthread. The one thing people need to remember is that when you take out technical debt by using a framework or library, you are basically entering a contract to do things their way. Take great care when you break this contract.
A lot of terrible UI code may be acceptable as it rarely infects the rest of the system where a smaller design bug in a tiny utility library may end up causing worlds of pain even if it's rather elegant code that could be reused on other projects just fine.