Here's the problem with inline filtering of SMTP transactions.
1) The RFCs mandate a server to accept multiple recipients--100 minimum per RFC 5321 (inherited from RFC 2821 and RFC 821).
2) A server can only accept or reject a message for all recipients.
Theoretically a global rule shared across all recipients could be implemented in a way that rejects at the transaction level. But because you also have to implementing lazy, per-user filtering (or more importantly, per-user whitelisting), in practice the architectural and engineering focus is on filtering after accepting the message and closing the transaction.
Without the ability to provide immediate and accurate failure responses upstream, filtering issues are left to metastasize and fester. (Because of spamming and spoofing mitigations bounces are next to worthless in terms of proper integration into the end-to-end software stack.)
One of two things needs to happen with SMTP.
1) RFCs drop the requirement for multiple recipients per transaction.
2) An extension mechanism is added that permits per-recipient transaction responses.
I think the only practical option is #1. Both cases require some amount of infrastructure patching, but for #1 it's extremely minimal and in most cases none at all. #2 is infeasible, at least without #1 preceding it (i.e. once you can no longer rely on batch sending as part of the basic SMTP command set, you'll have to support the extension.)
Once that's accomplished vendors who don't implement inline filtering can be rightly criticized and shamed. As inline rejections become more prevalent, mail being effectively black-holed will become a thing of the past and we'll finally begin to see proper back-pressure (literal and figurative) return to the e-mail network. There'll be more pressure on large vendors like GMail to improve their systems and policies once the fog of complexity and plausible deniability lifts.