We actually want to make this restriction a normative requirement, one day, but we don't know how to phrase that.

I'd like to refrain from applying editorial patches that move us further away from "normative requirement".

Recommendations are expressed in "should" idiomatically. This is actually an ISO/IEC rule.

Note that normative text does not mean it is mandated. Under the linked ISO/IEC rules above, by definition, recommendations are also parts of provisions as the normative elements of a draft standard. Even it is not a part of the mandatory requirements of conformance, it is not explicitly marked as "informative" and it has effects on positive ("allowed") judgement of conformance on some optional settings of the standard features (similar to those like conditionally supported features), hence normative.

A quick search of \recommended reveals some similar uses (with "should"), so the rejection is problematic. @jensmaurer please confirm if other instance of \recommended should follow the decision here. I doubt the should not, because I see the history in N4867 suggesting it is "to address ISO/CS 017 (C++20 DIS)", and this seems nothing different here (except that the text here is never in some note). Adding the format is about QoI of consistency in the current draft. How to change the wording a mandatory requirement is another story (and largely non-editorial). Before the change is adopted, if we have the consensus to make the rule mandatory as the future direction, better add one more statement about it in the note section following the normative text.

Edited my earlier comment to say "normative requirement" and "editorial patches".

That means: This is a sensitive area of wording. I don't want to accidentally do something editorially here that isn't the intent of SG1 and/or CWG. If you have constructive ideas how to improve the situation around forbidding out-of-thing-air values, feel free to write a paper to SG1.