I briefly read through T72901: Users can change the content model of other users' user pages to CSS or JS and I'm not sure I understand why a separate user right was implemented here. It looks like @Jackmcbarn tried to raise a concern about this as well.

Broadly, CSS and JavaScript user subpages are a weird special case, so we should probably treat them as such. Is there any reason not to fold content model changing back into the edit user right?

My particular interest in this issue comes from the fact that this issue is seemingly blocking MassMessage's new ContentHandler-supported subscription pages from being used on Wikimedia wikis (T92795).

It's not just a security issue; it's a usability issue. There isn't any sort of UI associated with changing the content model for a given page (T72592), nor (that I'm aware of) is there any mechanism for limiting which namespaces can have which content models (no Phab task yet, but probably should be). Trying to undo the edit which introduces the new content model fails with an exception (T73163). I'm going to guess that no one really knows what happens when someone tries to launch VisualEditor against a non-wikitext page, but we'd need to test that before allowing this in a namespace where VE is turned on. The feature needs a lot more polish before being deployed on a widespread basis. @daniel has even suggested in one thread (somewhere) that this should never be done by an end user, but instead be done via handler-specific code.

This is the first I'm hearing of MassMessage being blocked, so I've started asking questions in T92795. I think it should be possible to get the new version of MassMessage unblocked without having to resolve all of the problems I've identified above.

In T92794#1120516, @RobLa-WMF wrote:

I'm going to guess that no one really knows what happens when someone tries to launch VisualEditor against a non-wikitext page, but we'd need to test that before allowing this in a namespace where VE is turned on.

Solved two years ago: T49456: VisualEditor: VE should not become active on non-wikitext ContentHandler-type

In T92794#1120536, @Krenair wrote:

In T92794#1120516, @RobLa-WMF wrote:

I'm going to guess that no one really knows what happens when someone tries to launch VisualEditor against a non-wikitext page, but we'd need to test that before allowing this in a namespace where VE is turned on.

Solved two years ago: T49456: VisualEditor: VE should not become active on non-wikitext ContentHandler-type

Oh good! Glad to be wrong about that one. That gives me some hope that all the various gadgets, etc also take content model into account, since the css/js case has been around for a while.

In T92794#1120516, @RobLa-WMF wrote:

nor (that I'm aware of) is there any mechanism for limiting which namespaces can have which content models

ContentHandler::canBeUsedOn() allows contenthandlers to limit what namespaces or even pages they can be enabled on. Only Flow, SecurePoll, Wikibase, and Gadgets 2.0 implement it though.