Has been able to draw a red triangle for almost 20 years, on nearly every GPU released from a few dozen vendors. It transparently gets faster without you having to do much.
As a result of everyone having to writing code like the above, as opposed to assembly code specific to each GPU, the GPU vendors have been able to change their architecture tremendously over the years to adapt to changing process technology tradeoffs and add new features.
They've been able to do this in part because 3D graphics is a well-enough-defined domain and can be reasonably API-ified, but I could easily see things having gone a different way; people would be arguing about whether the ARM of GPUs would conquer the x86 of GPUs, given the massive install base of the incumbent. Instead, to some extent, anyone who can write an OpenGL compiler can play.
On the other hand, that same path has shown to be quite problematic, right? Lets say you have 10000 verticies, that's 10000 function calls to make. Sure, you could precompile a display list, or use some other work around, but we've finally come to the point where it is not fast enough anymore. Welcome to opengl 4, i'll miss the easy to understand glBegin blocks.
You're right that giving the OpenGL runtime information piecemeal (one vertex at a time, repeated every frame) is no longer acceptable for many apps in terms of performance, but I'd argue that that's not a strike against the abstraction layer per se. We've gone to a world where the code I posted was the only way to go, to a world where that works but is slow, and people who care about performance use display lists and vertex buffers and shading languages. However, most graphics code still feels like it's about graphics -- vertices, triangles, groups of triangles that share properties, lighting, shading -- and not about the registers you need to poke to set up the rasterizer on such-and-such chip, or how to optimally pipeline shaders to get the best hardware utilization.
The abstractions we have now are more complex than ever, but they are still, for the most part, in the problem domain -- it is possible to do weird things to your code for performance tuning, but it's just not possible to go as far with it as you can for a machine whose behavior is specified and guaranteed at a very low level.
It helps a lot that for the entire history of video cards, said cards pretty much all share the same goal- rendering a 3D object.
It can be argued that all a CPU does is crunch numbers, but if you spend much time with a limited processor, you quickly realize a good CPU (or in my case MCU) needs to be very versatile and flexible.
For CPUs, you need to at least allow programming at a much lower level because of the greater diversity of workloads. The average programmer will never write anything that cannot be specified in C, but they will certainly use such code (operating systems, for one). A good CPU needs to be versatile and flexible, but most of the good stuff doesn't need to be exposed to third-party developers.
Even CPUs' architectural transparency has its limits. You could squeeze a few percent out of your parallel code if you knew exactly how writes and reads were ordered on a particular system. As a rule, however, whoever made your CPU will not tell you; there's the 'trade secrets' thing, sure, but more importantly, telling you would impede their ability to do things a slightly different but better way next time, because your code would rely on the old behavior in ways that cannot yet be automatically detected or fixed. Instead, they specify a memory consistency model[1][2][3], an interface you can code to once and rely on for future generations.
