I would be very careful with such bold claims. If you take a look at the numbers in that blog (up to 50% slowdown on OpenGL), it becomes painfully obvious that this guys OpenGL path is doing something horribly wrong. Personally I have witnessed balance going both ways depending on the position of the bottleneck in the pipeline (NVidia, modern GL4 code versus comparable DX11 code). However, differences were rarely significant (and again, both ways) and can majorly be attributed to the differences in the ASM generated by the GLSL and HLSL shader compilers.
OpenGL's OS portability is better, yes, but it's graphics hardware portability is actually significantly worse.
Plus D3D is faster:
DirectX is also significantly faster than OpenGL on most Windows implementations
I'll second that. I've consistently found the same, and so has this guy: http://aras-p.info/blog/2007/09/23/is-opengl-really-faster-than-d3d9/
It is very difficult to compare different graphics APIs on a performance level, especially if they use different paradigms. I would guess that in 99% of all cases a person claims that API x is faster than API y, the difference can be attributed to incorrect or suboptimal usage of API y. A call to function A may be more efficient than a call to function B on one API, but it may present itself the other way round on the other API. Accommodating such differences may require a substantial change to the rendering logic and possibly even to rendering algorithms. Most people don't do that and quickly slip into what can be a pathological case for one API or another.
A clear exception is the D3D9 draw call overhead mentioned in the blog above. Other than what the blog claims, this behaviour is well documented and perfectly reproducible (and acknowledged by Microsoft). Fixing it was a major improvement of D3D10.