The first paragraph of section 3.5 states two positions that the RFC holds on Content-Transfer-Encodings:
(1) “allows newly defined MIME types to permit content-transfer-encoding;” and
(2) “allows content-transfer-encoding for message/global (see Section 3.7) [sic].”

The second position refers to and combines with section 3.7 (namely the “Encoding considerations” paragraph) to support my interpretation that implementations should accurately parse "message/global Emails with non-identity Content-Transfer-Encodings” (how I have paraphrased it).  For quick reference, “non-identity” refers to the “quoted-printable” and “base64” Content-Transfer-Encodings.
The first position “suggests” a wider breadth, but I do not think its words “necessitate” it.  For, the RFC lists only one “newly defined MIME type;” whereas a media/MIME type in general (in this case, all others) only affects the scope of RFCs that define/update it.

So I think my interpretation is precise if one defers to section 3 of the RFC.

Now, admittedly, two other sections in the RFC seem to contradict section 3.5 by broadening the scope (Abstract, p. 2; Introduction, s. 1, p. 3).  I’m not super hung up on how to resolve the contradiction; but I think, at a minimum, the missing support for “message/global” should be added.