I'll reserve judgment until senorjazz clarifies.
"2 1/2" is 2.5, even by a generous reading. If it is not 2.5, that is an easily avoidable mistake in technical writing. A few more minutes proofreading the user manual could have saved you many half-days in support, señor.
It wouldn't be all on one day a week, because that would be "one day a week" rather than "two half-days a week". Again, presuming good technical writing. So a four-hour stint on support, twice per week. That's only 40% as bad as five half-day shifts per week.
I presume four hours. Obviously, "1/2 day" could also plausibly be 6 hours or 12 hours, or half of a work day of unspecified length, or a time equivalent to half of a work day, occurring at a time other than during ordinary business hours. He has previously mentioned he is available at any time, for paid customers, so somebody is checking the messages on weekends.
With respect to your anecdote, if you didn't write it down, it didn't happen. You still need to write up (and immediately close) the defect report, and attach the customer interaction reports. You don't work for the customer; you work for your company, who works for the customer. And the company needs to know what you did, and why it was necessary, because when you are gone, so is the portion of institutional knowledge that lived only in your head. Your story tells me that this everyone-on-support practice enables workers to cut corners in the development process. It's only more efficient until reaching a certain scale, at which point it becomes a liability.
Your story might also give a corporate attorney some stress. As a company employee, you should never apologize on behalf of the company in a way that even suggests the company might have been at fault for anything. That type of says-nothing, customer-placating apology is an acquired skill.
Would the apparent advantages remain if each person were required to go on a "ride-along" with a dedicated customer support person? Silently listen in on their interactions? Like pair programming, except the support person always does all the driving? That might also be useful with sales staff, to improve requirements definitions. Or with management, to smooth out inefficiencies in process and status monitoring. Why not just make the whole company developers, doing other people's jobs? Because even though developers might be objectively better at customer support than a customer support representative, the work done on customer support does not generate enough additional revenue to pay them a developer's wage while they are doing it. Economic specialization separates the jobs, and pays at different rates. People do what they are best at individually, and exchange the results via trade and communication. Cross-trained generalists only work at small scales.
That's why small, niche companies can run circles around established behemoths within their niche. But they can't scale bigger until they squeeze the reliance on robust individuals that apparently makes them so agile out of their system, and replace that with robust processes.