Apparently Special:Mute is not enabled by default. This is bizarre and inconsistent behavior.

To make the whole special page appear, you need to set $wgEnableSpecialMute = true;, and to get it to display something meaningful and to be useful to users, you also need to set $wgEnableUserEmailMuteList = true;, and this is assuming the usual email notification related globals are already set and that user-to-user email is enabled.

We don't have similar feature flags for e.g. expensive maintenance special pages (other than the generic catch-all $wgMiserMode), so these should definitely also be phased out for the feature appears to have been in core since MW 1.30/1.34 if the relevant MW.org manual pages are to be trusted regarding the $wg variables mentioned in the task title, so I think it's safe to call the interface "relatively stable" at this point.

Furthermore, perhaps most relevant to my future plans, having the special page stashed well away and it being very email-centric prevents fixing things like T180920: userboard blocking (SocialProfile) in a sensible, reasonable manner: by interacting with and using core functionality in a third-party extension instead of lazily and sloppily duplicating code to have your own fork of Special:Mute, which will only create confusion in the end. (But that's literally what I did to have a proof-of-concept solution for fixing that task, but I don't exactly love the solution I had to resort to. The special page has a hook, SpecialMuteModifyFormFields, only used by Notifications (Echo) currently, but that doesn't matter if your main obstacle is that most MW installations out there won't even have the special page accessible in the first place...)