I suspect that implementing OpenGL ontop of Vulkan is the way of the future.
Eeeehhhh....
To me, OpenGL and Vulkan bear sort of the same relationship to one another that Xlib and XCB do: one is (relatively) easy to program for and lets you get good results right away. The other is much trickier to program for, but gives you much finer grained control over how the underlying layer is actually used, allowing you to get much more performance out of it. So there's room for both. And while basing OpenGL on an underlying Vulkan implementation is certainly feasible and may be logical -- as the Zink authors said, any optimization they can do can also be done by driver authors and then some, and there's still enough OpenGL stuff out there to where driver authors are going to want to make those optimizations.
There is a reason most browsers on Windows run WebGL through OpenGL and it's not because the driver support has been amazing. Same with MacOS which has deprecated OpenGL in favor of Metal.
Sometimes it's not a matter of what can be done rather who can actually do it so it does get done and these lower level APIs allow the general public to get it done instead of hoping vendors do.