Any other uninhabited enum can also be easily converted to any type, it's just a match x {}. There is vacuously only one way to perform such a conversion, so the question of whether to make it implicit is purely a matter of convienience, not correctness; it's just that Rust mostly avoids implicit conversions. The one from ! was added mostly for backwards-compatibility reasons, so that code continues to compile after the type of return changes from () to !. So ! is a bit special, but not enough to justify singling it out and introducing wildly non-uniform type system behaviour wherever it appears.
In other words, yes, I am quite familiar with that RFC. I know it's not stable yet, we'll get there, don't worry.
Have you thought about how this is going to interact with generics and non-exhaustive empty enums? The whole question of whether a type is inhabited or not is going to significantly compilcate reasoning about types wherever a for loop appears.
Decoupling the return type of the loop from the return type of the generator avoids this problem. This is what the Option<_> proposal does. There are other possibilities, of course; one may introduce for-else instead, or whatever keyword you want, I'm not particularly attached to the else keyword*. In the generators thread, I quite liked @canndrew's proposal, except the continue bit. Personally, I'd be more or less just as happy with that instead.
Consider then that the Option<_> proposal (in its pure form, at least) introduces fewer special cases and is much simpler than the one you champion, with inhabitedness checking. And the for-else proposal I linked above (fine, for-then) is just as expressive as both of ours.
What I meant by conceptual purity is making features orthogonal: useful independently of each other and interacting in simple, predictable ways. A well-designed for loop would be usable on its own, even if the language did not have any combinators at all. (Combinators aren't going anywhere, of course. But the for loop should still be usable as it stands.) The generator proposal hopelessly tangles together for loops and combinators even in its motivating use case (I cannot stress this enough), and you're suggesting to add reasoning about inhabitedness to the mix? No, just no.
* It does generalise well, though. Read especially the last bit. What a shame that issue got derailed by people who don't understand type theory.