For context, I've been working in game localization for many years, I'm a professional linguist and translator, my native language isn't English, and I'm currently working on a localization library for GZDoom.
Not only it makes sense, it's an example of basic string concatenation that is in use everywhere right now. Obviously, from a linguistic perspective it won't work as is, because there are noun declensions, word order, plurality rules, gender rules, etc. — I never implied the opposite. This is something that I, like thousands of other people in localization, deal with on a daily basis, because even today 99% of games don't care about that and don't make any concessions for languages with rules different from English. And yes, of course, over-reliance on concatenation is a prime example of making text that is hard to localize. But this is another issue entirely, something that depends on good decisions from the writers and the creative solutions of the translators, and potentially a proper and more robust localization framework. This is not a reason not to have the feature, however.
The framework is something I'm planning, including the possibility of pulling variations of strings to support declensions. We could use something basic at first, though. The switch to .csv was a step in the right direction; improving StringTable.Localize could be another.
If this is a no, I can go ahead and do my own implementation, but this absolutely looks like something that should be available natively to me. The way it is right now, it either deincentivizes people from using LANGUAGE at all, or it makes them use something like "You got %s", then using String.Format to push another LANGUAGE reference into that %s, which has the same potential grammatical issues while involving extra steps.