Hi, of course!
If I use language other than the main (https://il-en.openfoodfacts.org/ for instance English in Israel), every time I use Google search for finding products (which is preferable way for me because in-built OFF search is too slow, at least until search update), all pages in result will be only in default country language after redirecting. It means that every time I need to switch it to English interface manually anew.
If there are products, in which user country is not listed in “Countries where sold” field, then after search on OFF country subdomain I don’t get any relevant results and I need to click on “View results from the entire world” (all OFF interface is too huge, but this specific button is small and it is easy to ignore and don’t take attention to it XD), which redirects me to ‘https://world-xx.openfoodfacts.org/’ with same language. Maybe this is the reason why you don’t have this issue at all. Perhaps you are in some country, where almost all products are added to DB and to this list and they can be found with country specific search (French or USA I guess?). But I’m in a country, where most products still are not listed/added and it makes really hard to use OFF site, because on my main subdomain I can’t find almost anything, which is especially annoying because I know that all these products ARE in the database and this is one more reason why I stopped to use the in-built search. Because I just need to switch from country subdomain to global domain and vice verse without any real sense for that.
And, by the way, it is not clear at all that to make some products visible in a new country, you need to add this country to “Countries where sold” list. Because it is not specified anywhere on the website, that my search is limited by local products only and that this local product list is defined by “Countries where sold” data field. I wasted about one or two months before I even recognized it. Maybe there is some info about this stuff on Wiki page, but the Wiki has hundreds/thousands pages and it is strange to wait, that a new user/editor will read them all. Why all? Because it is impossible to know, where I need to read, when I don’t realize, it can be implemented in this way. And yeah, Wiki is not the best place for documentation…
Also after I was redirected to this global domain and finished to check this product, if I want to return to my country subdomain, the most intuitive way is using of top button with countries. But after I do that, I again get default country language in interface and should change it manually… So one more redirection
In addition, I like to compare same product in different languages and in current site implementation it is almost impossible mission. I need to guess, which languages can be available for some product and manually change [xx] part in https://world-xx.openfoodfacts.org/[product] to language codes, that I want to try to check. Very comfortable for using (it’s not 
). In the OFF app it is not perfect too, but at least I can do that.
Saving it in user settings could be a good alternative, with the benefits you list here (it’s easier to understand for users). There is however a major upside to having this subdomain-based system: for each country, there is a single subdomain in the user language, that is indexed by search crawlers. It ensures we have a good visibility on search engines.
It is not just easier, but must have in my opinion. Because the current realization is so non standard and difficult for understanding, that I’m not even sure I even saw this localization implementation before. It needs too much efforts and time to learn all details and nuances of this localization feature in OFF.
OK, after your explanation I see the logic behind this decision, but still I think it is too complicated logic. Even if I understand your desire to separate domains by countries, I don’t understand yet why languages are linked to country domains. For example, why can’t it work in this way: by default pages for https://ua.openfoodfacts.org/ are generated in Ukrainian for SEO reasons, but if a different interface language is set in settings, for this user this page will be displayed/regenerated in language, which this user wants to use? It will allow to drop this strange [country].[lang].openfoodfacts.org syntax and simplify it to [country].openfoodfacts.org or [lang].openfoodfacts.org only, which is much more spread and easy to understand.
And does it mean, that in the app it can be implemented, because the app content doesn’t have this SEO requirements?