Yes, it would be great, but it is most likely not happening anytime soon. As previously discussed on the WebGL mailinglist, Vulkan is strictly (and rightfully, wrt performance) working against all the security considerations that went into WebGL by design. A "WebVulkan" would thus not be much of a benefit, or even usable, if it's severly crippeled in it's features.
Even though Vulkan for would be of little gain for the web due to all the security considerations required, a WebGL backend should still be able to benefit from being built on Vulkan instead.
Due to the refinement of the pipeline and memory access, etc. provided by Vulkan, there's a lot of room for optimization.
___
Though on the other hand, even with additional overhead on a Vulkan web API, the improved state management and access to command buffers may still allow for smarter rendering with negligible overhead via JS
I completely agree and one could theoretically do away with things like ANGLE! Though, I also suspect that the implementor's overhead is rather large in contrast to the current way WebGL is implemented in Chrome and FF, which is currently a relatively 'thin' layer on top of OpenGL.
On the other hand the nature of implementation in Chrome, i.e. does seem to lend itself somewhat to a command buffer approach as in Vulkan.
