As I understand it the main "bug" that CORS fixes is that cookies were sent by default on cross-domain requests. This basically means that APIs were always authenticated no matter what site you were on. The funny thing is that browsers are stopping this cross-domain cookies anyways by adding domain isolation to prevent tracking. So this main feature of CORS is becoming obsolete. I wish that domain isolation was the initial fix (at least by default) but at the time it was thought that this backwards incompatibility wasn't worth it, so CORS is what we got.

There is one other feature of CORS which is network perspective. However it isn't an effective solution anyways due to domain rebinding attacks. So it is a best-effort mitigation at best. Blocking basically all client-side application use (RSS readers, API exporers, URL previews in chat apps ...) by default seems like a really high price to pay for this minor mitigation. A better approach would probably be browsers just blocking requests from public sites to internal IPs by default. That would actually be reliable (as long as you aren't abusing public IP space for your private services), block requests that aren't CORS protected (like form posts!) and would avoid the huge cost of CORS.

As it is if you want to do stuff client side you need to set up a CORS-stripping proxy server which is really annoying and creates a dependency on your service. At the end of the day CORS is a hacky mitigation for the braindead choice to send cross-site cookies by default. If you want real security you should protect your API via a real technical measure, not just hoping the the browser will block requests.