Also if a game company wants to use some obscure new DX function they can call up somebody at Microsoft and have a programmer leased to them until the issue is solved.
If the drivers for a major hardware company is having problems with a new DirectX API, You can be sure Microsoft will throw money at the problem to make it go away.
OpenGL doesn't have this vastly wealthy champion to ride in and fix problems in a timely fashion.
Valve would disagree with you:
We’ve been working with NVIDIA, AMD, and Intel to improve graphic driver performance on Linux. They have all been great to work with and have been very committed to having engineers on-site working with our engineers, carefully analyzing the data we see. We have had very rapid turnaround on any bugs we find and it has been invaluable to have people who understand the game, the renderer, the driver, and the hardware working alongside us when attacking these performance issues.
(source: http://blogs.valvesoftware.com/linux/faster-zombies/)
Seriously, there is no big MS anti-OpenGL thing going on; according to Alex St John (who should know, and who has been long enough out of MS to be able to say what he wants) the sole reason for D3D was not shenanigans, it was internal conflict: the Windows 95 team wanted OpenGL, the Windows NT team had the license, Microsoft wanted Windows NT to take on competitors in the workstation market, Windows NT needed OpenGL in order to do that, Windows 95 having OpenGL would undermine NT's position, so the NT team didn't let the 95 guys have the license. Without the license the only solution was a new API. (Note that Windows 95 didn't properly get OpenGL until OSR2.)
Believe that or believe it not if you wish; personally it makes more sense to me than MS inventing a new (and almost universally reviled) API just for the hell of it, especially considering that they really needed OpenGL for that workstation market. (If you've ever dealt with MS you'll know that they're fragmented enough to add to the plausability of this story; the fact that they're implementing WebGL in IE11 (admittedly layered on D3D11) is just further evidence.)
Regarding the state of OpenGL, reading issue #9 from the new GL_ARB_buffer_storage extension should give you enough of a feel for exactly what's wrong:
9) What is the meaning of CLIENT_STORAGE_BIT? Is it one of those silly hint things?
DISCUSSION: Unfortunately, yes, it is. For some platforms, such as UMA systems, it's irrelevant and all memory is both server and client accessible. The issue is, that on some platforms and for certain combinations of flags, there may be multiple regions of memory that can satisfy the request (visible to both server and client and coherent to both, for example), but may have substantially different performance characteristics for access from either. This bit essentially serves as a hint to say that that an application will access the store more frequently from the client than from the server. In practice, applications will still get it wrong (like setting it all the time or never setting it at all, for example), implementations will still have to second guess applications and end up full of heuristics to figure out where to put data and gobs of code to move things around based on what applications do, and eventually it'll make no difference whether applications set it or not. But hey, we tried.
This is the kind of thing that makes people trying to seriously use the API wince. D3D has no problems specifying explicit behaviour, and the hardware vendors have to live with it; the end result is that you as a developer get none of that nonsense; when you ask D3D to "give me a dynamic buffer, make it write-only, make it fast" you get a dynamic buffer that's write-only and fast.
You want another example? Did you know that the reason why glGetQueryivARB (GL_QUERY_COUNTER_BITS_ARB) was allowed to return 0 was so that Intel could claim GL1.5 support in hardware that didn't support occlusion queries? This kind of stuff is just nuts.
Yes, you're right about MS's recent model of tying a D3D version to an OS version, which is one thing that could make OpenGL appear a viable option again, provided that the ARB don't screw things up. Again.