Grepping thru the code finds a couple other instances of wfMsgForContentNoTrans(), apparently some kind of speed up around caching or something. Please see if they still make all the sense they perhaps once did, and are still justified.
Else why would one not want the translation?

NoTrans does not mean don't translate, it means don't transform (parse) it. Since it's being added as wikitext to the page (which gets parsed), there's no major issue.

There is too an issue.
Why in the world must that string on that page appear in Chinese, despite a perfectly good English string available, and everything else that could be affected by uselang=en affected. Why, why, why?

Because a good number of wikis customize this message heavily, and that would require them to copy it to all the language variants.

Well then Aha, Checkmate, there should be
IF they haven't customized it

THEN just like any other message, obey uselang= etc.
ELSE then do as you do now, but what if they indeed want to provide
three different translations, etc...

Anyway, the current way is not the right way to make a special case.
I fully support the goal, but the way it is currently accomplished
messes it up for the default case.

And of course this is all rather complicated so I'll just submit my
"high level analysis" above, and leave it as that...

Do get around to it LATER.

CLosing as WONTFIX - most wikis only localise it in one language. Others can always override this behaviour with $wgForceUIMsgAsContentMsg or {{int:...}} hacks.