Reader Peter accepts that the VC++ team might have different priorities than the C# or VB teams, but this leads to another question:

"Fair enough. Then I ask: What features did the C++ team put in instead when deciding not to put in feature supported by VB and C#? That is, if C++ doesn't have all the same features as VB and C#, it stands to reason it should have features they don't since the budget which could have been used for those features decided against can now be used for features NOT present in VB and C#. So what are THESE advantages to C++? "
 
Indeed, VC++ does have features not found in C# and VB.  Perhaps the most glaring example is support for this crazy thing we like to call native code.  :)  As obvious as that might sound, we did invest quite a bit in this release in native code support for things like improved optimizations (/O*, whole program, and PGO), 64-bit support (x64 & IA 64, native and cross-target), security (/gs improvements, secure libraries), MFC (WinForms support, better security, 64-bit support).  Basically, everything the VC++ team does to make native code development better is something that can't be done for .NET-only languages.  On a related note, I think we also did a pretty good job solving the problem of native-managed interop with C++/CLI and IJW.
 
Native code aside, there is pretty good parity between the languages.  Not that I expect that to go on forever, but it's nice while it exists.  There is some IDE stuff I can think of, such as the class designer and refactoring support, that I wish we would have had time to do for VC++ for this release but didn't.

Hey, we totally accept that our customers expect us to produce the world's most productive and highest performance compiler and tools for native code C++ applications as well as keeping on-par with C# in terms of .NET functionality as well as having tools and technologies that seamlessly tie the two worlds together.  This is certainly always the goal, but at some point you have to prioritize the stack of work and make sure the most important stuff gets done first/best.
 
Looking forward, the C# team is doing great stuff with LINQ, while we haven't announced any plans around LINQ yet.  For our part, we're definitely devoting a lot of thought to the concurrency problem and what developers will need to best take advantage of multi/many-core hardware.  We also have a uniquely VC++ problem to solve in determining the best ways to help native code Windows developers build software that takes advantage of Windows Vista and WinFX.
 
"Of course an obvious answer to the original question is that many people are very familiar with C++ as it has been around a very long time. Much longer than C# for sure, and VB was always a lot slower (probably still is). So C++ still makes sense in terms of being able to do things immediately instead of learning a new language (although conversion from C++ to C# is usually pretty easy)."
 
I might differ slightly with you on a couple of things here.  Firstly, you should theoretically see about the same performance between VB and C# these days, since both languages compile to MSIL (although you might see better MSIL performance from C++/CLI, due to the C++ compiler's more mature optimizations).  I would also say that conversion from C++ to C# tends to not be as easy as one might think, converting one curly brace language to another.  For simple code samples it's easy enough, but for real world software you're probably looking at a rewrite.  Heck, the QA cost alone for touching 100% of a code base would be VERY significant for many organizations.  Then there are all of the technical issues... template-based code tends not to translate well to generics (the latter being more limiting), pointer-rich C++ code doesn't translate well to C# in general, going from a header file / preprocessor world to a module-based / unpreprocessed world is a major seismic shift, etc.  Then there are all the in-house and 3rd party libraries that would need to be rewritten or replaced.  Again, pretty much a rewrite.  This is why we feel it's so important for VC++ developers to be able to leverage ALL of their existing code as they move forward into Whatever's Next.

"Also, a lot of previous code was written in C++. Remembering that one oboth high-level languages and object oriented programming is re-usablity, converting code form C++ (old) to C++ (new) is usually easier than converting from C++(old) to C# or VB."
 
Or, even better, it would be great to not have to touch existing (i.e., old but working) C++ code in order to reach .NET.  :)