The important part is that CORS can be used to relax any existing same-origin restrictions on HTTP requests.
1. If the same-origin policy isn't a problem for you, no need to change anything, obviously.
2. If you want to _tighten_ the same-origin policy, CORS isn't going to help you (as far as I know).
3. You can get rid of any request-related same-origin policy restriction with CORS, easily and in a way that is easy to secure. There is no need to build around it.
4. If you try to use something custom to achieve that instead, you're likely making a dumb mistake, because you're not only creating unnecessary work, but also most likely either breaking many more users than there are users that don't support CORS, or introducing a gaping security hole, or both. Usually both.
It allows you to make arbitrary HTTP requests across origins, even those that would normally be blocked by the same-origin policy, as long as the server collaborates and allows it, easily and in a secure way.
If you control the server (or can get someone to adjust it, or it already supports it), you can use it to make requests from one website to another, directly from the client.
For example, you can have JS on a site served on www.example.com make calls directly to api.someservice.net, without any kludges.
Any time you think of some contrived proxy solution, JSONP, or other kludges to bypass the same-origin policy, you want CORS.
For non-anonymous APIs, authentication can still be a challenge.