I have to agree that I think OpenGL - while slowing improving - has been in a unique position to actually change up the landscape of rendering APIs by doing truly forward-looking stuff like moving to explicit command buffer creation, dependencies, etc. But yet they seem to content to just follow DX (almost exactly), which is kind of sad at this point. And with all of their adding checkbox features, they still haven't addressed some of the basic problems in the API (direct state access is a good example, but I want to see far more than just that done)!
But that said, the reality is that the core concept of GL (design by democracy) has just proven far less effective than DX's "benevolent dictator" model. In the GL space there is no one that can really force people to standardize on hardware and features and quite frankly, that's why they end up following as well: because they can count on the features in DX being available on all GPUs as that is the primary design target.
Secondarily but not less important is the fact that no one writes good software infrastructure around GL and drivers. The Khronos conformance tests are a joke in terms of actually testing the entire API (including failure mode testing), which directly impacts driver quality. I shouldn't harp on GL too much here though as CL is 100x worse.
Regarding extensions, it's nice in theory that they exist formally in GL but it doesn't really matter much in practice. GL itself is already dicey enough that you can't really trust it to be fully portable (due not really knowing if you've inadvertently relied on a non-standard feature that just "happens to work" on one implementation), and once you add extensions you might as well be programming directly to a card's command buffer format.
Extensions are a proof of concept to allow key stakeholders to fool around with and then pressure the relevant standards, but none of these uses require a public mechanism like GL has. And let's not forget that all of the big GPU vendors have "unofficial" DX extension APIs as well that actually get used in games, unlike a lot of GL extensions.
I think GL's stagnation is just a sign of Khronos' inability to agree on anything. That and the gradual decay of desktop as a platform.
First the latter. If you have to use Linux/Mac, then there is no option whatsoever. Even on Mac, if and when Apple deigns to upgrade to a ~3 year old API, we'll get what has been available to every DX client for 3 years now.
And even on desktop, I see MS as gradually focussing away from it. Next gen consoles will be DX11 class and when they come out every one will switch to DX11 as their primary platform, leaving evolution of the API in nobody's hands.
As for the former, GL's bind to use model is atrocious. While extensions are talked up all the time, the good ones are languishing. Nvidia has been the real innovator here. Direct state access, bindless graphics are great extensions, have been around for several years and why the hell aren't they in core?
The situation on CL front is worse. The hw is miles ahead of CL and all CL has to offer is G80 class programmability. It's API is far better than GL, but the lack of updates is showing. Some years ago, IIRC, there was a presentation going around saying OCL will be here in 2012. Well, it's 2012 by my watch and.... It's telling that AMD decided to not work with Khronos for HSA. Let's hope they will have better luck.
Finally, Khronos has never developed/evolved a major standard as far as I can tell. GL was donated by SGI. CL was donated by Apple. GL has just been following DX since ~2000 and CL has nobody to follow so it is stuck.
The sad reality is, IMO, the only people who use GL are those who are out of choices.