Cookie-to-Header CSRF protection vs CORS

If I understand your question correctly, you are trying to compare things that are not comparable.

"Cookie-to-header" is a defense mechanism against CSRF attacks, although not a very good one as it relies on an attacker not being able to inject cookies into the user's browser. Better to tie a unique CSRF token to the user's session and put that value in forms and ajax requests. In any case, you shouldn't implement the mechanism yourself but use a modern web application framework that can do it for you.

Same Origin Policy is the core of the web browser security model and essentially says that:

1. Websites from different origins (different URL host, port, or protocol) can freely send credentialed (that is, including session cookies) GET, POST, HEAD, and OPTIONS requests to each other.
2. Websites from different origins however cannot read the responses of those requests. Though there are exceptions of sorts that allow for executing scripts and rendering images for example.

CORS (Cross-Origin Request Sharing) is not a security mechanism per se, I would rather call it an insecurity mechanism. It simply allows for an individual website to opt-out of the same-origin policy for some URL address/addresses.

About the compatibility, even IE10 supports CORS so I wouldn't worry about that. But yes, like said, even if CORS is not supported it just means that the same-origin policy will remain effective.

So, a bad CORS policy and CSRF are two distinct vulnerabilities, you can have one, none, or both.

CSRF vulnerability = You are not using CSRF tokens so that POST requests from malicious websites (which are allowed by the same-origin policy whether you use CORS or not) can make unwitting changes in your web application on the logged-in user's behalf. Those websites are still not allowed to read the responses, but they won't have to.

CORS vulnerability = You are allowing other websites to do something that breaks the same-origin policy. The worst thing you can do is enable the "allow credentials" for arbitrary/untrusted domains, which will let malicious websites use your web application on your user's behalf whether you use CSRF tokens or not because CSRF protection relies on the same-origin policy for it to work.

I hope that clears things up!