Google will be doing it for Android Q, most likely due to all devs that still aren't bothered to wrestle with Vulkan.
I'm not saying it isn't possible, ANGLE is a thing after all, but possible doesn't mean optimal.
Of course, given enough time, faster hardware will solve this.
Ah well-written OpenGL "emulation" on top of a Vulkan driver is most likely faster than than a badly maintained native GL driver, and you'll only have to worry about the bugs present in the one GL implementation you're linking against, not a variety of bugs across different drivers and driver versions.
Yes, the best scenario of the first case is better than the worst scenario of the second case, but personally i'm more interested on the best scenario of both cases - especially since we already have working OpenGL implementations that take advantage of how OpenGL is specified. I'd rather see a push to improve subpar implementations so they reach parity with the good implementations than throw all implementations out of the window because of the bad ones.
The issue with running OpenGL on top of Vulkan is that Vulkan's API exposes a very rigid and static view of the GPU and OpenGL is the exact opposite, allowing arbitrary state changes at any time. While actual GPUs are not as dynamic as OpenGL, they are also not as static as Vulkan so by implementing it on top of Vulkan you are forcing state changes that would not be necessary for the underlying GPU.
Also OpenGL being a higher level API provides for more opportunities for optimization than Vulkan (a very common example would be display lists which thanks to their immutability and opaqueness can have a large number of optimizations applied to them - something that both Nvidia and AMD takes advantage of, especially Nvidia which performs very aggressive optimizations on them).