I agree the devs should not do full-on support - that's of course just waste of money. But, that's different from spending maybe two hours per quarter with the customer support agents, just listening in on the calls - it can be quite revealing and sometimes there are issues one is not even aware. Plus hearing it from an actual human, does something to your sense of priority about such issues.
One company I worked for had very cyclical sales spikes, culminating in Christmas week each year. During that week everyone did operations, we had developers out in delivery vans carrying parts of the extra large orders to customer's houses, and at least one back in the office mostly handling calls from customers and suppliers.
Without fail that week generated a stack of minor improvements that could be implemented in a matter of days in the new year, because we were out there using the software we wrote, and had the necessary knowledge of how it worked to spot places where we could save people cumulative days of work with a 30 minute patch.
If you have to constantly tell customers to RTFM, you have a poor product. Or at least poor documentation. But no amount of documentation can paper over fundamentally poor product design, because docs are also technical debt.
Even if devs aren't taking calls directly, there should be a product manager communicating this feedback to developers.
What you've said here is exactly why the CTO should be on the support calls with the most problematic customers. They need to be the ones who shield the rest of hte company from letting this happen, and the only way to do that is to experience it first hand to see just how disruptive some clients are.
Ideally there should be some first line who deals with BAU customer support but completely separating value delivery from support bakes moral hazard into the org design.
You waste hours because the customer couldn't be bothered to read the manual. They'll ask you to be their IT staff if you let them.