That's a typical misunderstanding of purpose of CORS. Regardless of your website setting or not setting CORS, an attacker with a modified browser or a custom browser can ignore it. That's not what CORS protects from - CORS protects against a non-modified browser uased by Joe Random User installed via a factory/distribution path being tricked into doing something against the site policy, therefore exposing the user.
My beef with CORS is that I have to encoded the validation logic into its HTTP headers.
But maybe what I want doesn't fit in its headers, e.g. I want to allow requests from *.example.org. So then I am writing server code, and if I am writing server code anyway, why have the extra step of encoding validation logic in CORS headers in the first place?
Is it really that much more expensive to check the Origin header than to check the Authorization and Cookie headers?
The problem is that existing servers don’t generally check origin headers, so browsers needed some other mechansim to understand which requests were safe.