I think the issue is that you might have a bit of misunderstanding about the purpose of SOP/CORS in the first place. An important point that often gets missed is that the SOP doesn't forbid you from sending data to a different origin - it only prevents you from reading the response from the separate origin. You say this:
First I thought it may be so that an XSS breach into a web app doesn't
allow the attacker to send critical data to himself
And then clarify that the attacker would still be able to send data to himself by enabling some CORS headers on the receiving server. However, even that is not necessary. For simple GET and POST requests the browser will still send the request to the destination server, and that server will be able to receive and act on it normally without any issue what-so-ever. The only thing that will change as a result of the SOP is that the browser will refuse to allow the calling script to receive the response from the server [**exeception at bottom].
That's really the key. The same-origin-policy is all about refusing to let origin A read anything from origin B unless explicitly allowed by origin B. That is why CORS headers are set on the receiving server, not the origin server. If someone accidentally visits
facebook.com has explicitly said otherwise.
Of course the primary use-case for this is with access credentials. The browser will automatically attach cookies from
facebook.com to every single request that goes out to
Access-Control-Allow-Origin: * back on all requests. Note that if a server does that it cannot also set the
Access-Control-Allow-Credentials: true flag on. Browsers do not allow you to let everyone read your stuff and also send cookies along to all requests.
** I said that SOP/CORS does not stop the browser from sending your request. There is an exception to this rule. In the event of a "non-standard" request the browser will send a "pre-flight" verification request. Specifically, it will send a request to the endpoint with a request method of "OPTIONS", asking the server what kind of requests it will accept. If the request being sent doesn't match then the browser will not send the request in the first place.
Edit to add
Obviously your main question is "But if no cookies are involved then why even block reads in the first place?". I aimed to get that with my original answer, but let me try to address that more directly:
You're looking at security from the wrong perspective (in this particular case). You're effectively looking for a reason to deny access to a particular privilege (i.e. "why can't I do that?"). A much more robust way of approaching security problems is from the opposite direction: everyone should have the minimum privileges they need and they should only be given additional access if there is a reason. Instead of asking "Why can't I do this?" the better question is "Why should I let you do this?".
When you look at it from that perspective the default policy of the SOP to block all read requests unless explicitly authorized makes much more sense and is basically just standard security. Yes, people can circumvent this security step by doing things like making the request via a server. However, the fact that a security step can be circumvented doesn't mean it is a bad idea. There are lots of ways to circumvent the lock on your car door, but that doesn't mean you should just stop locking your car. Good web security is about defense-in-depth: layered security so that if a weakness is found in one area your system can still be secure. The SOP and read restrictions is basically just the very first layer of security for web applications.