On this I think it does more or less the same as MediaWiki: the sysop does not see the emails of participants, not even via API.

The sysop sees the email addresses of recipients already anyway by running an SQL query in the database if they operate the system anyway.
Running SQL queries is what I've been doing so far and it's cumbersome. Thus my request to allow this on an API level.
(I don't mind how MediaWiki behaves as that software covers different use cases.)

Yep indeed. I just mentioned MediaWiki to talk about a similar situation, where being a "sysop" does not necessarily mean being a sysadmin with CLI / root access.

As compromise, maybe introducing a role, such as "Blessed Administrator" / "Super Mega Administrator", perhaps assignable only from the command line, might be an interesting compromise that I could see being approved by someone. So, without changing the level of trust of the "Administrators".

(I'm against this, but I don't have the time to go into details right now. I suggest a CLI tool (like ./bin/user) to expose this information).

I think updating the user script is a good idea if this functionality is needed.

For completeness, my arguments against this:

• User's email is "private information" (PII), not to be exposed under normal conditions. There are a couple of places where a user's email is legitimately exposed (e.g. User Approval Queue), but those are rare.
  
  Adding a code path where PII is exposed to an approved user raises the risks of a bug exposing this information to un-approved users.

• Admins are not expected to bypass permissions in the system; The range of things that's hard-coded to "admin" is small, and we want to narrow it more. The idea is to reduce the amount of code that handles permissions.

• Adding a "super-admin" role goes against the goal of "reduce critical code paths".
  
  Traditionally, we've always considered the CLI access to be the "super admin". Running CLI scripts requires a very high level of access, which basically includes full access to everything (including the ability to change code and directly manipulate the database).

The underlaying use-case ("occasionally produce a list of all registered emails") sounds like something that can be satisfied by a CLI script (+ maybe configure auth.email-domains).