Most users are on mobile these days, and picking your preferred language is an unskippable step of setting up a new phone.
My hunch is that accept-language is far more accurate today than it used to be.
This does not address, or more precisely it even prevents the notion of:
> I might prefer some sites in Danish, but others I'd like to have en English.
, i.e. what you set in your OS or UA (browser) is always one preferred and optionally some fallback languages. I second that granular per-site control would be preferable for me either: some texts I prefer in my mother tongue (news, non-tech encyclopedic articles), the rest, namely technical documentation I prefer in English. (Also, I have very bad experiences with localised GUIs, where 1. familiarity with English "original" vastly helps when searching and 2. translations tend to range from bad to hilariously comical.)
But I must admit that most websites serving of content in multiple languages, support client-side pref pretty well, so the situation is not so terrible, in my experience.
Yet, the problematic of content negotiation and user <-> agent <-> author (provider) information passing is interesting and I'd say even under-engineered, and currently terribly suffer from security (anti-tracking) constraints.
(Lately, there was some development in "Client Hints": https://developer.mozilla.org/en-US/docs/Web/HTTP/Client_hin... )
EDIT: Best initial way to determine a user's language. MDN is right that overrides should be possible. https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_ne...
Accept-language is accurate, but just isn't easy change it which is required to handle all the possible situations and get the right answer. Still everything else is worse.