> Direct3D is far easier to use.

I disagree completely, i can whip out a quick tool for a bunch of tasks much faster using some adhoc OpenGL code than anything related to Direct3D. Direct3D might be easier in some scenarios like writing some rendering backend that you can then ignore and only use it via a layer (but then the same applies to any API, including Vulkan), but i find OpenGL way easier to work with directly than any other API.

> In a haphazard, difficult-to-use way that lags the state of the art.

Haphazard is subjective. I find OpenGL easy to use. As for the "state of the art", it isn't something i often even care to think about.

The only thing i found missing with OpenGL is raytracing support, though that is a very low priority for me right now (i don't even have a GPU with hardware RT) and even if i decide to implement it, i'll most likely use Vulkan-OpenGL interop just for raytracing than rewrite everything in Vulkan.

> Because Microsoft controls DirectX, they can look at what the GPU manufacturers are doing, draw up an API spec for the advanced stuff and the GPU manufacturers would hew to that spec.

Microsoft controlling DirectX is a negative in my view.

> OpenGL is designed by committee, a committee largely staffed by ancient CAD software vendors who insist on backward compatibility and it holds the API standard back.

That backwards compatibility is actually a fantastically great feature of OpenGL - it means code i wrote and worked years ago, still works, so i can focus on other things!

If i ever find part of the code doesn't work good enough (e.g. i need to do something in a different way) then i can only change that part - and it'll really be up to my decision to do so, not forced upon me.

> There's a janky extension system in place to allow GPU vendors to add functionality -- in proprietary, mutually incompatible ways that require the developer to write multiple code paths per unit of extension functionality.

Most useful stuff is in ARB and even when you write multiple code paths it is still easier and requires less code than having to code against some layer with different APIs at the back end for each OS or whatever.

> Use a game engine. It's got back ends for DX, Vulkan, Metal, even OpenGL (although that may change).

There is a chasmatic difference between a game engine and a graphics API (also the rendering code in most game engines is really only a small percentage of the entire engine even if it takes all the marketing focus). OpenGL is great in that it is high level enough to allow ease of use but not high level enough to force any framework-like functionality on you - you are free to design your renderer as you like.

Also because it is a standardized API there aren't random programmers waking up some morning and deciding that the design for their library/engine/framework/whatever could be done a bit """"better"""" and then going forward to break the API, making everyone who depends on it waste time getting up to date with their whims. `glClear` will always be there and do what it is supposed to do without someone thinking that it'll be a better idea to -e.g.- have separate `xxClearColor`, `xxClearDepth`, `xxClearStencil` in a vain and pointless refactor to avoid checking bit checks because that is slow (or whatever useless micromicrooptimization they come up with).

> If you must code to some 3D API, use DirectX.

DirectX is supported only on Windows (DXVK, etc are just hacks to play games whose developers do not want to make good Linux ports and cannot be relied on), controlled by Microsoft who likes to break the API in substantial ways every major version (older versions still work but you can't mix new and old functionality like OpenGL's extension system allows) and much harder to use compared to OpenGL.