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.
