Why does Graphics APIs especially 3D, still remain very much low level? I think 3d graphics is still not as ubiquitous as it could be perhaps due to complex and low level APIs.
It’s not just remaining low level, the trend has been moving steadily toward lower level. The primary reason is performance. It’s hard to squeeze the best performance out of the high level APIs. Another reason is because the people who care the most and get involved in the API and standards committees are people who know the APIs and their limitations inside and out, and care deeply about performance; people like game engine render devs, browser developers, OS developers, and hardware developers. And so newcomers and the ease of learning these APIs aren’t well represented. On one hand, there’s a valid argument to be made that people can write wrapper libraries if they want easy-to-use libraries. On the other hand, some of us really miss how easy and fun using SGI’s GL library was before it turned into OpenGL.
Earlier versions of GL were indeed a lot of fun and easy to get started without much learning curve, but very easy to get into a pickle and blow your foot once the project gets reasonably complex with everything being a state in the context.
OpenGL 4 was a huge shift and felt like such an improvement once you got used to it. It was a bit more work to set things up, but it was so much faster and had a lot less messy global state.
Products in the game space heavily differentiate from one another by "showing more" data (textures, models, detail, etc) or "doing more" with data - (massively multiplayer, more physics, ai, sound) or "doing it faster" - (more fps, low latency, etc)
Local compute resources are finite, and if you want to target the widest market, then you need to fully utilize mainstream hardware; which means anyone willing to do the grunt work benefits from a higher quality product.
Anyone that wants to explore graphics programming should start with middleware, 20 years ago we would use something like Open Inventor or VTK for that purpose.
No need to always start by learning on how to render a triangle or a rotating cube from scratch.
Because the need for higher-level, easy to use environment is served well by middleware, the so-called "game engines", Unity and Unreal.
There's intermediate level APIs, like the old OpenGL 4 and DirectX 11, or slightly more modern portable alternatives like bgfx and sokol; on the web, there's three.js.
The subject field is complex, the applications are also primarily complex, so there's not much value in something that lets you "easily" drop a few cubes on an endless plain (like the VRML of old days). There's no 3D equivalent of "I'll make myself the web site for my barbershop" that started the Web 20 years ago. (or, to be more pedantic, "the page for my high-energy physics experiment" 30 years ago.) Nowadays even the Web is hellishly complicated. Maybe if VR/AR takes off (any moment now), there will be need for "simple 3D", but I suspect it will be handled by custom "easy" versions of Unity/Unreal rather than people writing to a "simpler 3D API". The way people aren't making barbershop sites in "simple HTML", but going to Squarespace.
Classic OpenGL is anything but low level, and quite fun to learn. But it turns out it's a poor model for modern hardware (as opposed to early 90s SGI graphics workstations with architectures very different from modern GPUs), which resulted in impedance mismatches that made writing performant drivers (and performant client code) quite difficult. So modern graphics APIs went down an abstraction layer or two to make it easier to write code that corresponds to how GPUs actually work. But programming against something like raw Vulkan requires a vast amount of boilerplate code (that used to be handled by the driver) to get anything on screen, so a reasonable middle ground probably looks something like OpenGL 4.
