Except the only thing to suggest that this is intentional is that it is how it’s implemented. The design and use of code blocks elsewhere wouldn’t lead to this being assumed, and multiple people over the various issues have assumed that the exception would still be raised even if the finally block exits early.
There’s a very obvious way to handle an exception when writing a try/except block. If someone has deliberately chosen to handle exceptions in that very construct but without using that construct as intended, they ought to be less surprised when they find out that they should’ve just used it as designed.
No, it would noisily break the code 
Exceptions that were being swallowed would no longer pass silently. Code that intentionally uses return from finally to change the return value (weird, but okay) or to stop executing code in the finally block (when not raising) would continue to work exactly as they do today.
The alternative is to noisily warn about the code in the importer, making it difficult for libraries to suppress when they know that it’s okay.
But I’m not trying to argue the alternative, or else I’d just write a counter-PEP. I’m trying to establish why it isn’t even mentioned in the PEP as a potential alternative, given that it results in less dangerous behaviour and fewer compatibility issues.