This can happen even if the sales people does not mean to sell vapor.
At least in my experience, they seldom have the domain or program knowledge to pick up on nuances in the client's question, leading them to think they correctly answer "yes our program supports that" while in fact the program does not support exactly that.
As a dev I'm not often involved in sales meetings, but every time I have been in a sales meeting I've averted some form of vapor.
The sad part is that most of the times the client is fine with us not having the exact functionality they ask for, but understandably get upset when they only find out about this post-sale.
Engineering teams often have a disparaging view of the sales teams, but usually the sales team is just selling what is needed to get the sale. Sometimes this is 'misplaced', but in my experience of enterprise software it's more often the case that a client has a genuine requirement and the engineering team thinks 'feature x' is close enough, but the client disagrees (and the client will obviously be right about what their requirement is, and if feature x is close enough is just a matter of opinion).
I guess you mean that as "the client thinks they're obviously right", as in my experience they're surprisingly often wrong about what their requirements truly are. Sometimes spectacularly so.
Most of the time this is because the decision is being taken too high up in the organization, so they don't actually know what their employees actually do or need. If not that, then it's not uncommon to see X-Y problems creep into requirements.
Requirements are ultimately customer/user requirements/wants, not universal truths.