First, it's not even close to being "worst of the lot".
Second, there might or might not be a middle ground, but you're not proposing it, Microsoft isn't proposing it and no one else is proposing it. In that context, bringing up non-existent, maybe-or-maybe-not better solution isn't advancing the discussion. In theory everything is possible but in practice WebGL implements a well understood model that has been in use for decades (just like canvas implemented a well understood model for 2D graphics). If we want fast 3D graphics in the browser, and we do, building on top of well understood technology is definitely the way to go (compared to trying to reinvent extremely complex technology that took years to perfect in the currently dominant standards (Direct3D and OpenGL)).
I disagree with the notion that it's OK to adopt a flawed standard just because no better proposal exists. A better proposal could most certainly exist if it was agreed that it should exist and resources were committed.
The OpenGL API has a ton of legacy baggage. Nearly all of GL 1.0 is deprecated and some parts of the API have endured multiple cycles of deprecation. Improving on it would not be difficult.
GLES is even cruftier than OpenGL, because they removed a bunch of functionality but didn't simplify the API. So you have all sorts of parameters and options that literally have no purpose. The documentation frequently says things like "The blah parameter controls yada yada. It's value must be zero." That's gotta be mighty confusing for a web developer doing 3D graphics for the first time.
The design of OpenGL is optimized for stateful, fixed pipeline, immediate mode drawing, an extinct paradigm that is unsupported in GLES and WebGL. The modern paradigm of shaders and GPU objects is radically different and demands an API tailored for it.
The continuity of OpenGL has been justified by its established ecosystem. Game developers prefered one patched up API to a new API for every generation of graphics hardware. But now hardware architecture has more or less stabilized and it's the developers that are new. Let's give them a fresh start instead of a badly mutilated API that, frankly, I think most of them will find impenetrable.
Second, there might or might not be a middle ground, but you're not proposing it, Microsoft isn't proposing it and no one else is proposing it. In that context, bringing up non-existent, maybe-or-maybe-not better solution isn't advancing the discussion. In theory everything is possible but in practice WebGL implements a well understood model that has been in use for decades (just like canvas implemented a well understood model for 2D graphics). If we want fast 3D graphics in the browser, and we do, building on top of well understood technology is definitely the way to go (compared to trying to reinvent extremely complex technology that took years to perfect in the currently dominant standards (Direct3D and OpenGL)).