This is a bit if a laundry list of things but is probably best tackled in one big push. 

This issue is distinct from MDL-53266 / MDL-34732 which tackle how moodle can intercept the technical email bounce message and then call the various internal moodle api's to process them.

This issue is about improving the internal api's in a way that should work for any bounce processing handlers, in particular external ones like if you use AWS SES, or Sendgrid, etc and they do the bounce handling and then fire off a webhook to tell the application to some thing.

All the logic here is basically rubbish and it's been bad forever and never been fixed because the whole system is broken.

Specific things to improve:

1. Have a clear pathway for different types of bounces, eg hard bounce, soft bounce, spam complaint etc. For instance a hard bounce should immediately stop that email address from being sent more email. A soft bounce should be similar to the existing logic. A list of bounce types and actions https://aritic.com/blog/aritic-mail/practices-to-avoid-most-email-bounce/
2. The logic with email_send_count and email_bounce_count makes no sense for anything other than new accounts. If you have an old user who has been sent 1000 emails in the past, and then their email is closed, then you'd need to send them another 200 emails which will all bounce before the defaults would trigger. It should have nothing to do with how many emails they have sent, a better rule would be 'how many of the last N emails have soft bounced?' and I'd suggest it should be stop their email if 100% of the last N emails have bounced and N could default to something like 3 or 5.
3. There should be clear logic and ways to recover from an intermittent soft bounce problem. 
4. There should be an admin gui for exposing and dealing with these issues and resetting emails
5. There is a non zero amount of db io around recording and tracing all of this and at the moment this is all wasted because it's all broken. Yes we should fix it, but even when it is fixed I think this should be open in somehow, either only on when VERP is configured, or have a config.php flag for the cases when moodle isn't handling verp but a 3rd party thing is via webhooks.