There is a lot of reasons for OpenGL ES 2.0 on desktop but I especially like to picture it by "for the purpose of convergence". This includes computers, tablets and mobile phones but also the web through WebGL which is pretty much a Javascript binding of OpenGL ES 2.0. In practice we can imagine that it would be a great to be able to port directly a mobile phone game to a desktop platform and minimized code changes, the gap between between mobile phone performances and ultra-book laptop being not that large for example. We can also imagine authoring and prototyping GLSL shaders or even applications on desktop before using them on mobile devices.
EGL, WGL and GLX? What's the way forward? When EGL was originally announced, it brought be a lot of hopes, hopes that we will finally have a unified API across all platforms to handle the OpenGL contexts. That was in 2003... An early "leap of faith" hapenned when Sony announced that the PS3 would run OpenGL ES 1 + ES 2 level of extensions and EGL. Unfortunately, OpenGL ES 2 has basically never been used on the PS3, Apple created it's own flavour of EGL (EAGL) and only AMD exposes EGL on desktop.
On AMD side, OpenGL ES 2 is brought to desktop thanks to EGL and a dedicated SDK is provided which makes it significantly different from using OpenGL on desktop. A dedicated OpenGL ES 2 DLL for the implementation is provided and I believe distributed with the AMD Catalyst drivers.
On NVIDIA side, the strategy is different because OpenGL ES 2 is exposed through WGL. The idea was to make OpenGL ES 2 an OpenGL "profile". When I first had a look at it, the implementation would expose all the OpenGL extensions which made me think something like "Not that joke all over again?!" and I didn't waste any time with it. However, things have changed because now when creating an OpenGL ES 2 context, only the OpenGL ES extensions are exposed and the drivers is even trying to report all the not ES compliant requests as errors. I expect this to be a challenging work in progress so once again report your bugs!
A last option on Windows is Angle which brings support for both OpenGL ES 2.0 and EGL 1.4 on Windows by translating OpenGL calls to Direct3D 9 calls. It is used by both Firefox and Chrome on Windows. Angle might be the only way to get OpenGL ES 2 running on Intel hardware. There is no news from Intel about OpenGL ES 2 or EGL support but our experiences tell us that they are most likely going to be last at the party.
It looks like that Mesa is currently providing the best implementation: Not only Mesa supports EGL 1.4 but the implementation can load OpenGL, OpenGL ES, OpenGL ES 2 and even OpenVG. However, it's not clear to me whether it can load the proprierary implementations or not. At least, AMD provides EGL 1.4 and OpenGL ES 2.0 implementations through the its SDK.
On NVIDIA side, OpenGL ES 2.0 is exposed by GLX_EXT_create_context_es2_profile in a similar way than on Windows.
The Linux world is turning its back on X.org to adopt Wayland which uses exclusively EGL making its support not only desirable but required by proprietary drivers to run their OpenGL ES 2.0 or even an OpenGL implementation.
Windows 8 x86 follows the same behavours than Windows 7 however Microsoft did a large cleaning of APIs on Windows 8 for ARM which implies currently no WGL or EGL. The cleaning, or actually the not ported yet, is so drastic that even XNA isn't supported on Windows 8 for ARM. Considering that Windows 8 for ARM target tablets and I guess ultra-book kind of laptop it seems unresonnable for Microsoft to avoid the Adreno, Mali, PowerVR and Tegra chips which software stacks have mainly mature over the years with OpenGL ES 2.0. In such case, implementing EGL sounds to me like the most reasonnable option for Microsoft. Another possibility would to use Angle on Windows 8 ARM to get the OpenGL support.
Apple is definetely moving toward the convergence of MacOS X (renamed OS X for Mountain Lion) and iOS. However, beside development tools there is no OpenGL ES 2.0 on MacOS X. For EGL, Apple only supports it's own flavour, EAGL, which is basiccaly EGL in Objective C with no access to the framebuffer as we much render to a colorbuffer.
On the library point of view, only GLFW supports OpenGL ES 2 on desktop through the WGL_EXT_create_context_es2_profile and GLX_EXT_create_context_es2_profile extensions in the version 3 work in progress. EGL supports is on the todo list and I certainly hope it will include desktop support. FreeGLUT 2.8.0 released less than two months ago doesn't support OpenGL ES 2 in any way but I hacked it to add the ES2 profile approach... It tooks literrally 15 mins to add it to say how easy it was to do!
So what the future of OpenGL ES on desktop? First of all, it mainly passed by WebGL because this is how real time graphics can reach everyone and not only people interested in games or specific graphics software. GLX and WGL looks nearly dead as the last version of GLX, GLX 1.4 was released in 2005, and Microsoft is certainly not going to move WGL forward. Do we really need updates of these APIs? On other end, the Khronos Group seems to be still actively working on EGL as version 1.4 was released less than a year ago and a quick reference card is available without forgetting that the embedded market, where EGL is everywhere, is fast growing.