I think "conceptual debt" is a poor choice of phrase here, as one important kind of technical debt is the sort of software design debt where your domain model ends up being a poor fit for your domain, often because the domain concepts themselves shift. (For those interested, "Domain-Driven Design" is a great book relating to this [3].)
I also find the "worse than technical debt" headline irritating. It's the sort of, "the thing I specialize in is way more important than the thing you specialize in" thinking that is poisonous in a team environment. Which one is actually worse depends a lot on your product and your business conditions.
[1] https://medium.com/@vijayssundaram/user-experience-debt-c9bd...
[2] http://andrewchen.co/product-design-debt-versus-technical-de...
[3] http://www.amazon.com/Domain-Driven-Design-Tackling-Complexi...