Sorry, that does not convince me.
You're assuming that everybody is a language designer. Many Python users actually have little language design sense, and you shouldn't need to have it in order to be able to use the language. People are productive by learning to recognize and copy patterns, but their pattern recognition isn't guided by what you can reason out from thinking about how the implementation works.
An issue with except clauses in particular is that during normal execution they don't get executed, and hence they are often not tested carefully. (Witness the evergreen bug of having a typo in your exception logging code that takes down production.) In the case of the proposed except clause this will probably mean that people will add except clauses to for-loops because they've read somewhere "for-loops can now have an except clause" and never read the rest of the description, and then they'll add a non-functional except-clause to a for-loop, thinking they've solved a certain potential problem. So now future maintainers have *two* problems: the exception is not caught when it was meant to be caught, and there is a mysterious except-clause on the for-loop that nobody knows for sure why it was added.
I don't think there's a solution that solves the specific issue without confusing most people. Users of for-loops should probably do one of three things:
1. Don't worry about exceptions in the iter() and next() calls.
2. Put a try/except around the entire for-loop and don't worry about whether the exception came from an iter() or next() call or from the loop body.
3. Rewrite things without a for-loop, like Serhiy showed in his first message. This is ugly but the need should be very rare.