I think the issue is that you can't really have it both ways. If you want the users to be able to fix their own accounts once their email addresses issues have been sorted, then they need to be able to manually initiate a new confirmation email. Given it's a manual operation, it is generally a fairly safe thing to do - having the system send automated emails to an invalid email address is a bad idea.
If you were to fully block them, then users wouldn't be able to fix the issue themselves and would have to rely on contacting forum technical support - and even then, the only thing you're going to be able to do is reset their account and send a new activation email to verify it works - and if it doesn't you get exactly the same situation as if they had tried it themselves.
I don't think there's really a better approach here than what the software already does?
The alternative is to use an ESP the provides suppression list capabilities - for example, SparkPost adds all hard bounced emails (and spam-blocked emails) to a suppression list such that it doesn't matter how many emails you try to send, they'll simply block them - this is mostly to protect their own sending reputation. There are tools you can use to remove the email from the suppression list if you're confident the issue has been fixed.
They even maintain different suppression lists for transactional vs non-transaction emails - so if someone labels your newsletter email as spam, their email address is added to the non-transactional block list, preventing further newsletter emails being delivered, but they'll still receive notifications from the forum and password reset emails, etc. That's assuming you're sending emails marked as transactional vs non-transactional of course.
