LANG=Japanese appname in the terminal makes so much more sense.
The problem with that, is that very few applications are now isolated these days. You typically have a DB back-end, data export/import and RPC to other system services. Setting a different locale is error prone since some data might be simply misinterpreted and end up corrupted. And that is real problem, since lots of user data are actually stored in textual form (even in DB!).
IME, the per-application locale has its uses, but in real world it causes more problems than it solves. In fact, since most Linux distros support quick account switching, the cheapest solution right now is to use two accounts with different locales.
Forcing systemwide language settings is a broken concept. The fact my Japanese wife has to set her whole iphone to English to get google maps to say street names in the US while driving is a great real world example.
There is no sane way to solve that problem on the level of OS. (Even "primary language; secondary language" is not enough, since for example I have to deal daily with three languages (Russian, English, German).) Most of the time this ends up being in the responsibility of the application developers: if they care enough, they offer a possibility to use a language different from the system one.
Think of the flip-side: you might accidentally force all Japanese and all English iPhones to download both English and Japanese locale data. And this is pretty large amount of the data to just sit around idly, just in case when user might once decide to hear the street names in different language.