In Drupal, we aim to provide a generic language list, but in effect, people use languages for all kinds of things, and which languages from the general list are applicable to which operation are not possible to define.
1. Site wants to track English (US) and English (British) content separately. They don't want to have user interface translation for them (even if they have other languages, they want to have UI translations for). This means their list of languages for UI and content are largely overlapping but not equal.
2. Web application wants to offer its interface in various languages (think google search), but help pages and documentation on the web app will be available in a limited set of languages, and no intention to offer more. Language switchers in the documentation area (for content) would show less languages compared to the language switcher on the web app. Content language assignment should not show irrelevant languages.
3. A web site wants to expand into more languages, and while the new language pages are built out, they obviously don't want their language switcher links to show the soon to be added languages, so users are not confused that the content is not there yet, since its unpublished or permissions to be only seen by QA stuff at least.
To support these use cases, we'd basically need to refactor the "enabled" bit on languages to be a set of feature specific bits. Whether this language is enabled for UI translation (also very useful forwhere we are attempting a stop-gap solution for now), whether this language is exposed in language switchers, content language assignment, etc.