Not sure debt is the best analogy here.

Taking on debt (either with money or time) can be a good decision. Tech debt isn't the result of bad choices; it generally results from a desire to move faster. Debt is about borrowing a resource you don't have. With tech, it's borrowing time; you don't have time to write the cleanest, most robust code because you have to ship product in fast iterations. This is ok (some lean advocates would say it's the best choice) because, generally, the user isn't impacted from this debt. In time, this changes and the debt catches up to you in the form of 1) a slow, buggy product, 2) slow product development cycle, or 3) both.

If conceptual debt is real, it is collected very quickly. If you release a product that isn't understandable (mental model mismatch), you'll find out fairly quickly because it won't meet any user or business goals. The conceptual design of a product is so basic to the experience, it's easy to see if it's not working. People will usually start with "What the hell is this?" In that way, I don't think conceptual debt is that helpful.

However, I think low-level UX debt is real and that is what is discussed in the article. You can have a successful product (given a strong conceptual design and value proposition) with rough edges. Maybe some core workflow isn't as smooth as it should be, the layout is wonky, etc. This debt is accrued in the same way as tech debt; you forgo time to think through the smoothest path for a user in exchange for faster releases. You do this knowing that it will probably come back to you in the future and in the meantime, you can start working on smoothing out those edges.

I’d argue conceptual debt and technical debt are largely intertwined. I definitely agree that it’s best to do as much thinking up front as possible, which may include exploration projects (in code, design, or whatever).

I have a immense conviction in the power of a clear conceptual model, and the business benefits that come from clarity of thought in your product design.

I totally agree with this. It can be a difficult sell to management or clients, but it’s definitely the best way to go. Conceptual purity and locking things down at the front of the project helps the later stages.

Have encountered this more than once. It's a usability aspect that is often forgotten; that what the user is used to doing.

I don't know if I like the word debt though. In the real world, debt is what you get if you want to spend more than you have. In programming, you make it when you want to go faster than time allows, so you take shortcuts. Even though the essence of this article is still valid, it's about choices being made that are bad in hindsight. Examples of shortcuts in design would be not polishing your designs, not doing some form usability testing, not thinking about a design system, etc.