A URI is intended to identify a resource.
Resource refers to the actual thing being retrieved. On a web site, that's typically a page. In a REST API, it would normally be an entity - person, profile, widget, photo, etc.
HTTP headers tell the server things about the client - they don't describe anything about the resource itself, or provide any help in locating that resource.
Accept-Encoding tells the server that the client knows how to convert or decompress certain content.
Accept-Language tells the server that the client is in a certain locale and prefers content in that locale.
Authorization tells the server that the client thinks it is authorized to access a protected resource.
A common theme with the majority of these request headers is that the server is not obligated to honor them. An
gzip does not guarantee that the response will be compressed. An
ur-PK is likely to be ignored when hitting a U.S. site, unless they specifically support Urdu. And the server reserves the right to verify the
Authorization header and return a 401 or 403 anyway, if it doesn't like what it sees.
None of these headers are intended to materially change anything about which resource the server provides in response. The
Accept header is no different. If a client specifies
application/xml and the server only supports
application/json, then the server is going to send back JSON - not XML. More importantly, the
Accept header can specify multiple types, in which case the server is free to return whichever it prefers (or none of them). As you might imagine, this could easily lead to undefined behavior for the user, but let's ignore that for the moment.
The intent of a hyperlink is to link to a page - page being a certain type of resource. Or, you might be justified in the looser definition of simply linking to a resource, even if that resource is something other than a page (perhaps an image, or a data set). What it is definitely not meant to do, however, is link to a specific representation of a resource. That is for the client and server to negotiate, and the server to ultimately decide.
Accept-Language is an obvious example of why it might be problematic to allow hyperlinks to control headers. It doesn't really make sense, if you think about it. Each user controls his or her own language preference; it's configured in the operating system and/or the browser. The browser should always send the same
Accept-Language header, regardless of which page is being visited. If the server supports that language, great; if not, then it will respond with whatever language it thinks is closest.
If this could be changed by hyperlinks, then inbound links could essentially force you into the Chinese-language version of the site, even when your browser and operating system aren't configured to support that language. That makes no sense. If the site supports English, and your browser is English, then it should respond in English, no matter what the hyperlink says.
Likewise, if your browser knows how to display XML as structured data, and can look for XSLs to make it look pretty, but doesn't really know what to do with JSON other than dump it out as plain text, then forcing them to the JSON content by way of a link (if such a thing were possible) is an aggressively user-hostile behaviour. The browser should always be the one to say, "I know how to display X, but not Y, so I would really prefer if you gave me X".
I can understand why you might think it's logical to allow the user of a browser to override this decision. But the truth of the matter is that you're thinking of a few tiny edge cases like downloading a report; 99% of the time, when this choice exists, the user is not qualified or does not have sufficient information to make it.
To put it slightly differently, imagine your parents or grandparents going to download a file and being asked to choose text/csv or text/plain. Are they likely to know the difference? I don't know about yours, but mine often can't even spot the difference between a banner ad and an error message, so there's no way they'd be able to make this choice intelligently. On the other hand, there might be a glimmer of hope if they're given separate links to download an "Excel workbook" or "Text only" - which to them are actually separate resources, not just different representation of the same resource, and the URIs should reflect that.
The user can't be relied upon to understand that these two things are actually the same resource, but different representation. And without changing everything about the way the web works today, we can't assume anything about what they will do with that hyperlink. They might click, or they might right-click -> "save as", or they might copy-and-paste it into their address bar, or they might be using a download manager, or they might still be using IE6, or they might be using some off-brand tablet or mobile device with a proprietary browser... and in many of these cases, they're not going to get the content they want, because either they'll lose the part of the hyperlink that declares the content-type, or their browser won't support it.
Could the HTML spec have been designed 40 years ago to support a content-type attribute in hyperlinks? Maybe, although as I've described in the first several paragraphs, there were strong reasons against it, especially during a time when bandwidth and server resources were scarce and the idea of being able to download the same report in multiple formats (or, frankly, downloading any report at all) honestly hadn't occurred to anyone. But certainly in today's world it would be insane to try adding something like that to the spec; it would completely break backward compatibility and lead to the dreaded "undefined behaviour" in every existing browser.