Why is the Access-Control-Allow-Origin header necessary?

If I understand you correctly, you are saying why is the browser blocking access to a resource that can be freely obtained over the internet if cookies are not involved? Well consider this scenario:

www.evil.com - contains malicious script code looking to exploit CSRF vulnerabilites.

www.privatesite.com - this is your external site, but instead of locking it down using credentials, you have set it up to be cookieless and to only allow access from your home router's static IP.

mynas (192.168.1.1) - this is your home server, only accessible on your home wifi network. Since you are the only one that you allow to connect to your home wifi network, this server isn't protected by credentials and allows anonymous, cookieless access.

Both www.privatesite.com and mynas generate tokens in hidden form fields for protection against CSRF - but since you have disabled authentication these tokens are not tied to any user session.

Now if you accidentally visit www.evil.com this domain could be making requests to www.privatesite.com/turn_off_ip_lockdown passing the token obtained by the cross-domain request, or even to mynas/format_drive using the same method.

Unlikely I know, but I guess the standard is written to be as robust as possible and it doesn't make sense to remove Access-Control-Allow-Origin since it does add benefit in scenarios like this.

What initially bothered me with CORS policies was their indiscriminate application regardless of resource/type, I feel that sentiment resonates with your question quite well. W3 spec actually advises that:

A resource that is publicly accessible, with no access control checks, can always safely return an Access-Control-Allow-Origin header whose value is "*"

So while the scenario in @SilverlightFox's answer is possible, IMHO it was unlikely to be considered when writing the spec. Instead, W3 appears to be driven by an "everything that isn't explicitly allowed should be restricted" mentality in this instance, which backfires when correct headers aren't set or support is lacking by individual browsers:

• Rich client-side applications using third-party RESTful APIs where authentication, if any, is sent with every request so that there is no "session" to hijack (that's stateless for you!). Still, .json responses are subject to CORS so now you have to convince the third party to either implement jsonp, or a suitable Access-Control-Allow-Origin header, or give up and set up a tunnel to their endpoint (guess which one I'll be using).

• Webfonts are subject to CORS, although afaik only Firefox implemented this draft spec. This means that if you're using a CDN for fonts (or a subdomain for all static content), it best be *-enabled!

• Bonus herp derp points for CDNs which don't reply with an * header but echo the request Origin header value instead: if it gets cached on a proxy with an ...-Allow-Origin: domainA, your users from other domains will not be able to access it without cachebusting (which is kind of a setback in terms of CDN performance benefits).

• There are also a few fringe scenarios like using external images/videos with canvas.

These inconveniences when accessing *-suitable resources could be simply considered acceptable since at least CORS is in play by default when it matters most.