The opinion seems to be that Adobe does not allow this because not all browsers will provide this information to the Flash player. I have not seen a list of what browsers have this limitation, though I will speculate it must be older versions of popular browsers... Some of the evidence of this is that this is provided in AIR. In AIR, it is the runtime itself that makes HTTP requests. In a SWF running in a browser, the runtime relies on the browser. So restrictive browsers could be an issue on a SWF, but never for an AIR app.

Could another reason be security? In particular, cookies are passed back-and-forth via HTTP headers. There are numerous cases of cookies being stolen by malicious JavaScript, which has total access to HTTP headers. Adobe made a lot of significant security improvements between Flash Player 8 and 9. In a world of mashups, are they better off continuing to deny access to HTTP headers?

All of that being said, I recently ran across another case where this causes problems. I had a SWF that could be loaded by two different pages. It needed to show slightly different features depending and have a different look and feel depending on what page it was on. The easiest thing to do would have been for it to "know" what page was loading it by looking at the referrer on the HTTP request that loaded the SWF. This is a header of course, and thus not available. Instead a FlashVar could be passed in to tell the SWF what to show. That's a better way to do it, but required changing the code of the page hosting the SWF, which was not an option. The hack that had to be used was to have to logical copies of the same SWF, foo_A.swf an foo_B.swf. The SWF could then look at its this.loaderInfo.URL to figure out what to show.