The question still doesn’t make sense. Vulkan and OpenGL 3.3 are APIs, not libraries (they are implemented as libraries most often though).
Both are merely used to access the graphics hardware.
OpenGL is more abstract and limited, but can be made more flexible by jumping through hoops and raising the hardware requirements. It will also be slower due to the workarounds you have to add.
OpenGL ES (ES = Embedded Systems) is a reduced version of OpenGL for non-desktop-PCs (kind of), so a lot of the workarounds we could use in OpenGL would not work in OpenGL ES as the graphics hardware implementing it is more limited.
Vulkan is more flexible than OpenGL but it’s more complicated to work with initially. However, a lot of the workarounds would not be necessary as Vulkan is more feature rich than OpenGL to begin with.
The difference is essentially building a shed from scratch (Vulkan) where you get to pick every detail yourself OR buying a complete shed (OpenGL).
If you only need a shed fast, you’ll go with the pre-made one, it’s easier but also not as flexible. If you want to add a window to the shed later this could be problematic:
If the premade sheds design was very simplistic to reduce cost (OpenGL ES) it might even be impossible to add a window as you’d have to cut through support beams which go along the thin walls.
Given the right paintjob all sheds can look the same too. Their internal structure might be different though and impose limitations on what you can use it for or how easy it is to add another window. (Meaning you can produce the exact same image with these APIs, but how you get there and how troublesome it is varies)
These APIs are exposed by the drivers: if hardware supports Vulkan it’s likely it also supports OpenGL and OpenGL ES. However, low-end hardware will only support the lowest standards like OpenGL ES as the hardware itself is not flexible enough to support OpenGL or Vulkan.
Vulkan is the better choice for emulators because we’d have to jump through hoops with OpenGL.