It's likely that many Wikipedia accounts have a validated email address that once worked but is out of date. We do not currently unsubscribe users who trigger multiple non-transient failures and some addresses might be 10+ years old.
We should not keep sending email that is just going to bounce. It's a waste of resources and might trigger spam heuristics.
I'd propose adding two API calls.
One to generate a VERP address to use when sending mail from Mediawiki.
One that records a non-transient failure. That API call would record the current incident and if there had been some threshold level met, eg at least 3 bounces with the oldest at least 7 days ago, then it would un-confirm the user's address so mail will stop going to it.
For at least the second call, authentication will be needed so fake bounces are not a DoS vector or a mechanism for hiding password reset requests.
The reason for the threshold is that some failure scenarios will resolve themselves, eg mailbox over quota, so we don't want to react to one bounce. We want a history of consecutive mails bouncing.
There would be Mediawiki development component to this task to build the API, to add VERP request calls wherever email is sent, and an Ops component to route VERP bounces to a script (taking the mail as stdin, and optionally e.g. the e-mail address as arguments), which can then call the (authenticated) MediaWiki API method to remove the mail address.