This will affect a number of long-term active users.

Also: (1) before 1.12 there is an "emailconfirmed" group built-in MediaWiki; (2) By default all users registered for 4 days are confirmed - which means we only use one aspect to define confirmed users.

Also, a potential improvement is require users to send an email to confirm their account - this will prevent users from using most disposible mail services (e.g. 10minutemail) to confirm their accounts.

I think the main reason to want this is that for users with a valid email address, we can block suspicious logins and force an email check. For users with no email, generally the best we can do is ignore the login or prevent access to the account entirely.
Also if an account gets breached, it's usually only possible to recover it if there's an email address.

There would be a couple ways for an account to go from confirmed to unconfirmed:

• User changes the email address. Until the new address is verified, the user's email address is unverified.
• User removes the email address entirely.
• Bounce handler un-verifies the email address after MediaWiki messages bounce.

Adding a verified email address to the autopromote system is straightforward, but there's no auto-unpromote.

there's no auto-unpromote

The autoconfirmed feature works by checking it on-the-fly.

In T395207#10855618, @Bugreporter wrote:

there's no auto-unpromote

The autoconfirmed feature works by checking it on-the-fly.

yup, since auto-confirmed check is an implicit group and all the checks happen on the fly, there is no need to promote or un-promote someone.

If all users without an email would be automatically removed from autoconfirmed group, that is a huge user-facing change that would be impossible to understand for many of them. Given that receiving captcha is both annoying and bad for accessibility (see T6845: CAPTCHA doesn't work for people with visual impairments), if this gets implemented, there needs to be some sort of banner for users to explain that they need to add email to their account to stop captcha from happening. It might, however, defeat the purpose of stopping single-use accounts, since they would also know that, but it is the right thing to do nonetheless.

Admins will still have the ability to grant it manually ('confirmed'), right? We are not binding this to the (set of) rights, but to the user group (or, the autopromotion), are we?

Whether you, as an admin, should do it or not, given the cause known to you, is perhaps another thing for communication.

We could grandfather in existing users with a condition like (edits > 5 && emailconfirmed) || (edits > 5 && central_registration_date < [cutoff]).

(edits > 5 && emailconfirmed) || (edits > 5 && central_registration_date < [cutoff])

Please note that the default number of edit required for autoconfirm is zero - i.e. user become confirmed after 4 days - and this default settings is used in a number of wikis like Commons.

In T395207#10879485, @Bugreporter wrote:

(edits > 5 && emailconfirmed) || (edits > 5 && central_registration_date < [cutoff])

Please note that the default number of edit required for autoconfirm is zero - i.e. user become confirmed after 4 days - and this default settings is used in a number of wikis like Commons.

Though I suggested to raise it at T323948#9103374.