With that sense, they should write everything in Assembly, since if they put in maximum effort, no automatized tool (compiler) can beat its performance. There's a reason why programming in general is going into a less hardware-specifics dependent direction if you look at a long enough time-frame.
Anyways, I wouldn't worry about the performance so much. First off, compiling C# code is several times faster at this time than compiling C++ code, and from my experience, its slower speed doesn't seem to bother (C++) developers that much. Second off, the performance loss from managed code is unlikely to be noticeable in practice in the end (if it's gonna be, it will likely be caused simply by the more modular and more open form of the compiler). Third off, compiling is traditionally a very-well parallelizable process, so Moore's law is gonna help this area much more than most other areas.
Plus don't forget the fact that Roslyn can actually increase performance of C# code. For example, generics are one of the weakest point of C# performance wise, generic collections can be almost 2 times slower than collections written for specific types. It's already pretty easy to convert certain generic collections to be hard-typed with roslyn, as long as they're not used with any of the unsupported language features (and don't use any characteristics that require them to be runtime-generics, but that's pretty rare, and roslyn can also warn the programmer about them). By the time it comes out, there'll certainly be tools that do performance optimization on your code (run only when you actually need optimized code) before sending it to the msil compiler.
I've been playing with it a lot since it came out, and I am amazed. It's not that unique in its goals IMO, but, as with a lot of other stuff in the past, they made an incredible job making it actually work in practice.
Although Eric looks pretty firm about Roslyn officially only being aimed for code analysis, some other members of the team don't seem to be near as strict. It's already easy provide aspect oriented features with it, at least at class level.
I will actually be surprised if we can't add/remove language features to/from C# in a few years like we do with extensions for VS today.