The irony is that with OpenGL and WwbGL getting left behind, graphics programming becomes a bit more uniform across platforms as a result, even though the underlying APIs are different. They are based on very similar modern concepts. OpenGL on the other hand really shows its age and isn't a good fit anymore. Some newer things have been bolted on awkwardly over time, but they are either optional extensions or part of versions that are newer than what certain target platforms actually support.
Looking at the various rendering backends for our product, the OpenGL backend is the most byzantine one. The Vulkan backend has more code, but all of that is fairly sane. It doesn't have accidental complexity like having to pick the right GL function to upload a specific texture out of about a dozen possibilities depending on the texture type and target OpenGL version/extensions.
I don't, given that I did my thesis in porting a particle system from NeXTSTEP to Windows in OpenGL back in 1999, and am relatively confortable with Khronos APIs.
The only thing that saves Vulkan is that it isn't as old as OpenGL, with a similar timeframe it will get just as bad, or even worse given its complexity for the average graphics programmer that doesn't hold a master on GPGPU hardware design to understand the nuances of all those extensions.
Looking at the various rendering backends for our product, the OpenGL backend is the most byzantine one. The Vulkan backend has more code, but all of that is fairly sane. It doesn't have accidental complexity like having to pick the right GL function to upload a specific texture out of about a dozen possibilities depending on the texture type and target OpenGL version/extensions.