That's perhaps overstating the case right now. Vulkan is much lower level than OpenGL, not to mention the many libraries, engines, and tool suites built on top of OpenGL (and OpenGL's traditional competitors). Vulkan is an interesting development, but it's still very young and I'd say its future is far from certain. I think this article pulls out some of the tensions well, esp. in things like the differing perspectives of IHVs vs. ISVs.
Speaking personally, I'm mostly curious as to whether Vulkan is positioned to help show the way out of the GPU driver hell that the industry seems to be in right now. Related, will we see any vendors come forward with open source Vulkan drivers, perhaps even precipitating public discussions between IHVs and ISVs over software vs. driver vs. hardware performance issues? Hope springs eternal... ;-)
Robert Menzel's "Should I Switch to Vulkan?" flowchart is one way to get a quick read on Vulkan's positioning vs. other options:
Vulkan is much lower level than OpenGL but that's not very relevant - you can easily have a layer that sits on top and provides higher level utilities - the advantage over OpenGL being that your layer is transparent and a part of your code base/environment which you can debug and modify - not some BLOB driver.
Realistically the reason why Vulkan is not that interesting outside of AAA games is that OpenGL ES 2 became ubiquitous only recently and it took years for stuff like web browsers to implement it and then there's all the mobile fragmentation, and finally there's Apple with their own standards and API.
OpenGL ES3 is not even close yet and it's exposing tech that's been available for close to a decade now on desktop.
Best case scenario for Vulkan adoption is someone comes up with a really good OpenGL OSS/Apache licensed (no patents or copyleft) implementation on top of it, everyone agrees it's a good implementation and just ships that on top of native Vulkan drivers.
"esp. in things like the differing perspectives of IHVs vs. ISVs”
That does not surprise me. The IHVs used to write drivers with tens of layers of code, and now only have to write the lowest-level layers. That could mean a significant cost reduction for them, but that code still would have to be written and maintained.
The ISVs, on the other hand, will have to write those intermediate layers, possibly multiple times for different target requirements (speed vs display quality, for example; every single application could have custom-tuned upper layers), and (almost) for every single hardware revision (that may mean a growing market, which would be good for them, if they can find the engineers to take it)
ISVs also may have concerns that a new competitor will spring up to try and take this new territory (for example, engineers who now write the upper levels of OpenGL drivers for a hardware manufacturer might start a new company)
I’m not sure the IHVs should be completely happy, though. Third parties who will try to write those intermediate layers will need a very good understanding of what the hardware actually does, and that may leak what they consider competitive information (it may give competitors hints as to how to make their hardware faster, or it may give them more information to sue them for patent breaches for). Because of that, I would not be surprised if a lot of this information would be ‘given’ to ISVs under NDA. That would be bad for those wanting to write open source drivers.
