My understanding of the same origin policy is that it prevents scripts from making requests to resources outside of the domain from which they originated. One motivation of this is to prevent a malicious script from interacting with any other sites that the user might be logged into (for example, a malicious script from site-a.com might submit requests to the users banking site).
CORS relaxes this constraint since there are legitimate reasons why a script might need to make such requests; resources shared across multiple websites would be one example. In the above case, www.site-a.com might need to access resources at media.site-a.com or api.site-a.com.
One hypothetical way that this could be achieved would be for the originating site to publish a whitelist of sites (in the response headers) to which external requests can be made.
My understanding of CORS is that the browser will submit requests to any resource and depending on the response headers, will allow the response to be read or not; that is, if the response headers indicate that they will allow requests from the origin then the requester will be able to read the response body and otherwise not.
What is gained by the CORS approach of allowing the requests and inspecting the response headers over the hypothetical approach of disallowing the requests in the first place based on a published whitelist?