> by design the error messages sent to the browser are intentionally gutted
A CORS error is not "an error message sent to the browser", it is an error generated by the browser, because the browser has decided it cannot permit the request. (Though certainly a server can not understand a CORS request as such, and returned a weird response, which would then end up getting translated to a CORS failure.)
I think what the person you're replying to is trying to say is that the web-accessible error message (i.e., the one that JavaScript running in the sending page can read) is intentionally opaque and somewhat misleading, because a more helpful error message would leak information about the response that the sending origin isn't supposed to have. There's typically a more helpful error message in the dev tools (which JavaScript running in a page can't access), but you have to know where to find it.
The message in the dev tools is, at least for Chrome, extremely developer unfriendly: The blocked request is displayed in a very strange way, without any information that it was blocked, nor that CORS was the reason for it, nor how that decision was made based on the preflight request.
You have to already know from experience that these strange devoid-of-information requests have been blocked by CORS, then find the preflight request, and there you will find a bit more information, but still much less than would be possible to show.
Showing more information would, AFAIK, not circumvent the layer of security that CORS (or actually origin isolation, which CORS makes an exemption from) adds. My best guess is that this just had very low priority when building the dev tools.