There are websites out there, that will not be updated as soon as the first browser supports your proposal. Those sites will not check the XHR-Origin header and are therefore vulnerable.
Vulnerability example
Let assume you are logged in to your bank. Without logging out, you visit another website. This website sends an XHR-request to your bank to request a JSON response, which is used in the account history view.
Yes, this request will have a XHR-Origin header, but if the bank software is not adjusted, it will reveal sensitive data.
So it is the responsibility of the browser not to break existing SOP restrictions.
Is CORS fully SOP compatible?
The CORS specification makes a number of exceptions for which the preflight check is not required. Those are based on situations, in which the SOP was never enforced in the psat (e. g. form submissions).
The problem in the current draft is, that it is solely based on the Content-Type header, but web applications tend to ignore it.
There was a nice talk by Shreeraj Shah at Blackhat Europe 2012 on HTML5 Top 10 Threats: Stealth Attacks and Silent Exploits