The issue is that everybody does the minimum modifications needed to translate the C api into their language rather than the design the API as you would in that language.
The issue is also that, since graphics are a performance intensive and ergo low-level task, there isn't really a one-size-fits-all way of wrapping it up in a higher level api.
I can't speak for WebGL, but for OpenGL there are various frameworks and such you can use but at the end of the day most people end up needing specific access to the low level guts and you just end up writing your own code to interface with it.
No, the OpenGL API is a mess. It's not because it's an API to do a complicated task but merely because of it's 1990's legacy. Just compare the OpenGL API to the Direct3D API and you should see a clear difference.
The best (or worst) example of this is the OpenGL context, which is basically a global (actually: thread local) variable that tells which GL context and window should be drawn to. This context then stores a bunch of other global state, such as texture bindings.
The API was (probably) designed like this because in the early 1990's it was actually a major optimization to avoid pushing parameters to the stack when calling functions several times a frame. Many graphics API's of that era did the same thing. Also there usually was only one screen with one fullscreen "window", so why not make the "display" a global variable? Now 20 years later we are stuck with this shit because it became an industry standard.
OpenGL is a pain in the ass, not only for programmers but the implementors of the API. For example, take a look at OpenGL "texture completeness" rules (textures must have consistent mipmap levels, etc). Direct3D does not have an equivalent, because the API is designed so that all textures are always complete.
Unfortunately we seem to be stuck with OpenGL for a while. There's not much interest for redesigning the API and as far as I can tell (I'm a Khronos member), no ongoing effort to do so. Direct3D is a much better API but unfortunately it supports a very limited number of platforms (none of which I actually like to use).
There are several examples where something like this has gone horribly wrong. High level API's for "common use cases" tend to work only for writing one page examples for text books but are completely useless for anything more serious. One example of this is the CUDA API. They have a low level C API, which gives you a good but a little verbose programming API (because GPGPU is complicated). Then there's a high level API where you write the GPU code mixed together with the CPU C++ code. It somewhat worked for the examples in the Cuda manual but was useless for anything else.
OpenGL did have a library called GLU that did some high level things such as quadrics (for spheres, cylinders, etc) and tesselation of polygons. It was completely written on the CPU on top of OpenGL. It worked decently for some stuff. Direct3D has also some helpers, f.ex. to do some matrix math and load 3d models.
A library like OpenGL is probably best left to be a low level API for a low level task. A high level API in this case would be a 3d engine on top of OpenGL and there are plenty of those out there.
People are already making games in OpenGL and C. This was totally impossible before, using JavaScript. Redesigning the whole API would delay the process, and it would have to use OpenGL as it's own backend anyway, so you'd inherit a lot of the problems.
If you want something that's easier to use, wait until game engines for JS appear. This is supposed to be low level.
With NaCL you might end up being able to use OpenCL to construct your own 3D rendering stack and use it in the browser.
As far as I know, no-one has yet shipped a product that has a graphics sw stack written with a GPGPU api like OpenCL. It's an interesting project to do and you can do really cool stuff. However, practical it is not.
You also shouldn't forget that the GPU has dedicated hardware for graphics that cannot be accessed through a GPGPU API. The framebuffer can't be manipulated with a GPGPU API. Window compositing is largely done by dedicated hardware. Some GPU's still have dedicated hardware for vertex shading. If you try to write a graphics stack with a GPGPU API, all this hardware is left unused.
The issue is that everybody does the minimum modifications needed to translate the C api into their language rather than the design the API as you would in that language.