C# is nice (and my language of choice), but to think that they're going to switch en masse is a little silly.
C# is a better language than C++. It is conceptually cleaner and offers options that C++ does not (closures, lambdas, etc.)--but it's slower. Mind you, C# is a good glue language for interoperating between different native code libraries, but therein lies the problem: C# relies on native code libraries to do almost anything game-related. DirectX is C++. SDL is C. OpenGL libraries, likewise C. Physics libraries? Depends, usually C++. Why? Because C# is slower. Significantly so in some cases, such as when doing matrix computations.
The argument that C# has more features (I'm assuming you mean the BCL and other .NET libraries) is a misleading one. .NET has more features than just C++ and the STL, but that is a far cry from the full picture--there's Boost and there are countless libraries for C++ development, most permissively licensed.
C++ also has considerable inertia. It's what developers know. It's what they (currently) like. And while it's making inroads in tools dev, C++ be the primary language for game development in the foreseeable future because the underlying engine is most critical. Good programmers can write good code in C++; bad programmers (and there are a lot of them in the game industry, don't kid yourself) can write bad C#.
I'm just going to assume you know that C# is just a language and that it doesn't actually have any libraries nor as a language itself, any slower. So then I'm going to be using .Net in all my referencing.
In reality, I suspect that .Net will end up much faster than well optimized C++ now. If you haven't tried it recently, but with the Sun Server JVM it execute it much faster than the C++ version I had written (this was an algorithm sample); however, if speed is really a concern, nothing will beat hand-optimized assembly implementation of the same algorithm sample proved.
What's really stopping me from moving to .Net period is that I'm waiting for Microsoft to improve the JIT to improve it's execution speed to be more comparable to the JVM (I've read that it doesn't even unroll loops yet).
Now in regards to .Net making inroads into the gaming industry, I can name a good reason why that probably won't happen and it has nothing to do with speed. It basically is .Net relies on translating very specific data definitions to machine code. Those specific data definitions then make it very easy to reverse engineer the code. Now, of course there's obfuscators which make it harder to reverse engineer. It's still much easier than compiled binary code due to the type system, because you can see the different type groupings used by the code.
However, compiling C++ to native machine code you essentially lose all type information and only by analyzing hundreds (to thousands) of instructions can you start pulling out and definining structures, but it'll still be incomplete (have you tried any reversing of Dwarf Fortress?). In addition with a good optimizer you tend to lose function and parameter boundaries, sure there are identifiable functions, but watching the code accesses a non-standard parameter register for a parameter initialized in a function two calls away is always interesting.
Why would the industry care about how easy it is to reverse engineer? Well the first reason is they want you to pay for it, the second is that you don't want to make it easy for cheaters in online games.
Uhm.... I didn't plan on a wall of text...
In many cases if you are doing object-oriented design (which you actually can in both C and C++, though C++ makes it simpler by supporting objects directly), you will find that switch statements can be replaced by using polymorphism with objects.
First off, I would nearly never use much polymorphism in a static execution. I would take advantage of polymorphism in a JIT'd execution. This is because of lost performance due to extra overhead with dealing with extra memory (read: cache hits/cache misses). If you want a general idea how it works, take a look at implementing a COM object in C. You have your object in memory, you have your virtual function table, for every virtual function invocation you end up with upto 2 additional memory accesses and if you're doing complex memory intensive processing (read: games, Dwarf Fortress!) then odds are you've clobbered the cached page that holds the virtual function table.
Ok, I think that was more verbose than it should've been... I'll definitely shut up now.
A switch statement when used correctly will be best in either case, but you already knew that.