Yes, it does. Taking aim at GCC instead, a huge amount of GNU code will not compile without --std=gnu++11 instead of --std=c++11. Even more of it won't compile without a POSIX environment--even ignoring the build system and autotools. The point is that, in many cases, portability should be accidental. I.e. with relatively few platform-specific exceptions (which should be isolated and generalized) programming is done against the abstract machine specified by the C++ standard. That's the compiler user's part of the contract. The compiler developer's part of the contract is to implement a compiler that compiles the language specified by the C++ standard.
I'd say you idealize too much. Surely, a lot of code can be written in a platform-agnostic way, relying on the standard C++ only. But there is a significant range of tasks that benefit from compiler extensions, and that's not only OS-dependent things. Take manual vectorization for instance, this is a CPU-specific thing which by definition cannot be fixed in the standard. Generalized implementations are possible but IMHO they will never be as efficient. Or multi-module interfaces - the differences between OS implementations are too deep. Or for how long the "long long int" type was an extension? Look at extensions from another perspective. They are often a playground to test new features that may eventually, after usage experience is gathered, go into standard as a new feature. Only extensions are available here and now and not in a few years when the new std paper rolls out. This is pretty much like how it goes with libraries. Don't get me wrong, I'm all for fully conforming compilers. But objectively extensions are useful in some domains and eventually are a good thing. You don't need them, you don't use them. But should you need them, it's good they are there.
Sure, lack of full support for the language and the presence of bugs are a huge problems. However, towards the end of 2012, I'm not particularly irrated by the current state of C++11 conformance. I am irrated by set in stone "won't fix" responses to bug reports and broken, mis-implemented features.
I agree, this disappoints a lot.