tl;dr: "Conceptual debt" is what Ward Cunningham described as "technical debt". That thing you call "technical debt" is just a combination of bad habits, haste and apathy.
Personally I find it an improvement to have two terms that separate the concepts, if for no other reason that it underscores that 'conceptual debt' is a thing that matters a lot and isn't just 'the engineers can come in and clean it up later' type of deal, which technical debt often can be. Recognizing conceptual debt as something that all team members can contribute to, not just people writing code, is a profoundly different type of conversation than the ones you'll have today around tech debt where it's assumed a) stakeholders can't understand it and b) it's nobody's problem but the engineers: they create it, they pay it down.
I will certainly use the phrase.
When a major customer needs a new feature, do you hack that feature into the codebase to save the account? Or do you risk the account in order to add the feature The Right Way?
I think that we arrived here specifically because we don't have a term for the effect of careless code change. 'Technical Debt' ended up being appropriated as a term for it.
As much as it hurts my engineering sensibilities, 9 times out of 10, being hasty is better than not existing.
I've been adopting this rule of thumb that the first pass at a new product I can just dive in and treat it as a throwaway, since I probably don't understand the domain well enough to develop an ideal conceptual model anyways. The key here being to treat it as a throwaway and then return and do a rewrite from scratch once I have a better understanding of the problem.
I guess I'd rephrase your point about "one to treat as a throwaway" as saying that you should realistically expect to be moving back and forth between architecting the conceptual model and implementing it. I find it useful to first think about the conceptual model, then write some code for a while, then revisit the model and see what difficulties I've hit and/or what new good ideas I've thought of in the process, etc.
And to your point too about first thinking about the conceptual model, agree that you should spend at least a bit of time before doing anything else. Thinking through your modeling is something that doesn't take that much time and has such huge payoffs in terms of avoiding pitfalls. But often times it's just funner to start writing code so people do that.
It's always saddening to see programmers just dive in and start coding without planning / thinking about the problem first.
Honestly, that's not quite true. If you told management of a source of funding that could fund a couple of developer salaries, and could borrow at zero percent interest, and pay back whenever so desired, then they would rightly point out that the optimal time to pay that debt off is "never."
The key point about technical debt is that quality metrics need to be tied to actual costs incurred, not just 'the software fails to meet my standards.' For example, 'our customer support forum hasn't been updated in years and has been hacked' is a valid technical debt since your staff is now spending time fixing the forum, at substantially greater cost than upgrading.
But maybe removing all the trailing whitespace and replacing all the tabs with spaces has no business related expense, and rewriting your Django app in Go because 'that's where the industry is heading' is paying off the cheap debt first.
0% interest isn't the best analogy for technical debt, however, because technical debt often carries recurring costs that are analogous to interest. Every time you have to make changes or enhancements to a technically indebted system, the cost of those changes in time, effort, complexity, and bug hazard is higher than it would be in a clean system.
My argument is simply that if there is no recurring cost, it's not technical debt. It's just imperfect software that still works without demonstrated problems.
Speed and Quality need to be in balance.