I think your skewed world view is apparent here. MS and Intel certainly didn't come and say, "One of our top priorities is portability. How can we target our compilers to platforms that we have nothing to do with? Oh wait, GCC already does that!"
Of course not. Honestly, GCC has been an afterthought for most of the history of C/C++. It's only now that it is effectively dead that GCC has started to become competitive. MS was focused on Borland for years (and it actually didn't generally revolve around perf, but generally build throughput). Likewise, Intel was focused on SPEC against xlc and other architecture specific compilers.
And as I said in another post, they (GCC, Intel, MS) have different priorities. If your goal is to have a somewhat portable C/C++ compiler then GCC is the way to go. If you want the best perf/throughput on a specific target then MS and Intel are your best choice.
But with that said, I'm sure you know, that's not really relevant to the discussion at hand :-)
If we narrow the target enough, all comparisons become interesting. I am quite sure GCC will blow both Intel's and Microsoft's compilers out of the water when it comes to compile code for IBM mainframes. I am sure it's much better than Intel's when it comes to target my phone's ARM processor.
For me the Intel compiler makes sense in certain specific applications (many of my servers are not even x86), but the Microsoft compiler is absolutely worthless.
For example, code size, throughput, debugging, and optimization are all places that the Visual C++ compiler is superior than GCC. How many Windows games are written with GCC? How many top-tier Windows apps are written with GCC? If I'm writing a Windows C/C++ application, I'm going to either use Visual C++ or icc. I'll choose icc for code with lots of compute intensive loops or vectorization opportunity. VC is better when icache is an overriding concern.
Now that may not be what you do, but to say, "Who in their right mind writes programs for Windows?", I think says more about you than it does about the respective compilers.
Still, there is a lot more to programming than desktop applications that run on x86 processors under Windows. And embedded ARM processors outnumber desktop x86s by a large margin. I carry at least three of them with me at all times.
And Visual C++ targets ARM also, and has for years. One of the reasons I've heard bandied about as to why WP7 first party apps are so fast and responsive is because of the quality of the Visual C++ compiler. :-)
But you surprised me now: wasn't WP7 managed code-only? Has MS decided to allow native app code?
Regarding WP7, 3rd party apps are managed. But the core OS is native and 1st party apps can be native. For example, IE and the mail app are both native C++ apps.
Honestly, I think allowing 3rd party native apps would be a mistake in general. Although I'd create a partners program where you require devs to pay $10k and then go through a certification process, which allows them to ship native apps. Basically its the XBox model. Indie devs use managed code. Apps that are willing to go through the more expensive process get native access.
Why? Native apps introduce a bunch of problems that are a pain to deal with. For example, there a bunch of security issues and stability issues that native apps introduce. Additionally you have to target native apps to an architecture. It may lock WP7 into ARM, due to the ecosystem, and block it from moving, for example, to a new Intel architecture.