May I be as bold as stating that you fail to consider everybody's requirements, or at least that we are looking at this from a very different perspective?
The main OS on the market at this point is Windows, both for professional and personal use. In light of this fact you can scrap GCC and LLVM from the list already, GCC creates large cumbersome executables on windows. Sure MinGW isn't bad for meddling around and some small executables. But I wouldn't want to use it to compile things where performance matters, I've tried on several occasions. I must say I find GCC's capability to deal with the Windows Platform SDK quite remarkable at this point. But the end-performance is icky at the best of times. LLVM simply does not have any real windows port that's stable and performant enough for production software.
Before I continue I should probably also mention the code I write is mostly meant for hardware interfacing (I guess you could say drivers to some degree), simulation, and data visualization. All these things require high-end performance which I simply cannot find in the GCC or LLVM ports to Windows. And before you go off making bold statements about Windows not being fit for these sort of jobs, I disagree heavily. If the program that needs the simulation code runs on windows it doesn't make sense to run it on anything else than windows for small to medium scale simulations. Interfacing to remote systems is a hassle and generates a large overhead. For the very heavy lifting using C++ is pointless, Fortran still takes the gold trophy home in that area for me.
And while to the untrained eye the machine code generated by GCC and MSVC might look very similar, MSVC simply generates better code for hardware interfacing, especially its more predictable what happens when you use in-line assembly. The windows port of GDB also fails miserably for these sort of applications, while the MSVC tool chain does a decent job. For simulation it really starts to show though, MSVC simply generates more efficient code than GCC for Windows. Do note that this requires configuring the compiler correctly, something that's trivial to do for MSVC but requires digging through documentation for GCC. Other alternatives like the compilers produced by WATCOM, Digital Mars, Mentor Graphics, and a few others simply don't cut it most of the time. They're either unable to produce code that's capable of using all the resources efficiently, or behave horribly when things like CUDA are invoked. Then there is also the entire issue of data visualization, one of the most important aspects of software development in my opinion. On Windows its either use DirectX or die trying. I agree this is mostly due to Microsoft's doing but we're stuck with it. And no matter what you do, nothing quite beats MSVC when dealing with DirectX.
This also brings me to the point of more common desktop applications, the MSVC standard library works. If you try to use it like the one produced by the GNU project you'll indeed end up in trouble. Not to mention that GTK is a horrible badly documented excuse for a UI library. Qt is better but has licensing issues all over the place. Wx is lacking features in a few important areas. If you use MSVC it knowing its strengths and weaknesses you have a great *little* tool chian at your disposal. Tie it in with the full Windows platform SDK and you have something you can quickly produce a large application with. Frankly I don't care about the C++ standards, I'm very pragmatic about these sort of things and I'm happy if things work well. If I don't have to dig under the hood too much I'm happy. I don't care about the compilation speed, incremental building works very well and my desktop is more than quick enough for 99% of the cases.
