OK, both the question and Geir's answer show some serious confusion, so I'll try to clear things up a bit...
Same-origin policy (SOP) is a browser security feature that limits interaction between websites. Broadly speaking, it prevents site A from viewing the content of site B. This is important, because otherwise if you were logged into a site like Facebook, any other site that wanted to could view and even take actions in your Facebook profile! This would also apply to things like online banking, shopping, or business management. It is necessary for the security of any web site that requires you to sign in or otherwise authenticate yourself.
Some of what SOP prevents is simple enough to understand, like with XHR (XMLHttpRequest) and Fetch, where it prevents the requesting site from seeing the content of the response. However, it does NOT prevent the request from being sent, in most cases (it does, by default, block some kinds of advanced cross-site requests, such as with custom headers). After all, there's no point preventing simple requests - GETs or POSTs with standard content types - because a malicious website A that wanted to attack B could simply create an HTML form that automatically submits itself to B with whatever data the attacker put in it, and all of the user's cookies for B would be included with the request. SOP also prevents most interaction between iframes and their parent pages.
However, there are some things that SOP does not prevent. For example, a web page can include scripts and images from external sites. Since web advertising is almost always done by loading images and scripts from external sites (and for that matter, web tracking works the same way), SOP does not prevent advertising in general. SOP also does not prevent CSRF, unless there's protection such as an anti-CSRF token being used, in which case SOP is important(otherwise the attacking site could just read the anti-CSRF token from the target site, and then submit it with the forged request).
Cross-Origin Resource Sharing (CORS) is a way for site B to tell a browser "hey, I want you to relax the same-origin policy with regard to site A, but only in these very specific ways". More specifically, the most basic thing CORS can do is allow standard XHR and Fetch requests (which are made using JS) to read the response content, which is normally not permitted. It can also allow more complicated things, like allowing site A to set specified custom HTTP request headers (which is normally not permitted) or content types outside of the ones that HTML elements can submit (which is also not normally permitted). For example, CORS might be used to allow two sites that trust each other (like security.stackexchange.com and stackoverflow.com) to share information using client-side requests. Or it might be used to provide a web service API that a site like Twitter can use to programmatically reveal the content of tweets to other sites, again client-side (i.e. without the browser needing to ask the current site's server to send that request for it).
However, to be clear, CORS doesn't "protect" anything at all. All CORS can do is poke holes in the protection of SOP. CORS was developed to provide a safer way around SOP than the things some sites were doing instead, like JSONP (which was a clever hack but a security mess). CORS lets you relax SOP in only the ways you want to, for only the sites you want to.
Hopefully that also answers why both SOP and CORS are useful. In general, you shouldn't enable CORS on your server (that is, send CORS response headers) unless you need to, and if you do need to, you should enable it only for the stuff that needs it. I've seen some sites that use CORS so liberally that they've basically turned off SOP for their whole site, which would let any malicious site on the whole Internet view and control the misconfigured site for any user that was logged into it and visited a malicious site.
