I don't claim that this is necessarily the best solution, but I've dealt with a similar problem (translating English language names into native versions for all the languages -- i.e. German => Deutsch) by creating a separate language file just for language names and using a custom view helper for displaying them:
* ext/intl fulfills a majority of L10n needs, and, due to being in C, is
much, much faster than anything we could write in userland.
* As you note, keeping the CLDR up-to-date was a major hassle, and
hugely inflated the repository size -- and the majority of user needs
fell within what ext/intl offers, making the offering questionable.
Additionally, due to the size, there were performance issues that led to
a need for robust caching. While we could transcode the XML to native
PHP data structures, those structures would be large enough to impact
resources. Caching only what is used works, but it requires some pretty
difficult strategies to accomplish well.
If enough people are interested in having CLDR-backed L10n, we can
likely add it in a future release, or, better yet, via a module.