Because they only need to write one compiler for C# to CIL – which is the hard part. Making an interpreter (or more often, Just-In-Time compiler) for the CIL per platform is relatively easy compared to writing a compiler from C# to (per platform) executable code.

Beyond that, the runtime can handle anything that compiles to CIL. If you want a new language (like F#) you only have to write one compiler for it and you auto-magically get all the platform support for things .NET supports.

Oh, and I can take a .NET dll and run that on windows or on linux via Mono without recompilation (assuming all of my dependencies are satisfied).

As for performance, it’s debatable. There are “pre-compilers” essentially that take the CIL and make native binaries. Others argue that just-in-time compilers can make optimizations that static compilers simply cannot. In my experience, it depends a lot on what your application is doing and what platform you’re running it on (mostly how good the JITer is on that platform). It’s extremely rare for me to run into a scenario where .NET wasn’t good enough.

.NET has an intermediate language (CIL/MSIL) and platform-specific implementations of a platform-independent runtime (CLR) for the same reason Java does. Microsoft intended C# to directly compete with Java, and it does, on the OSes that Microsoft targets (its own).

The advantages, even though .NET is only supported on Windows platforms (or other OSes that have a .NET workalike like Mono/Linux), are similar to Java:

• Managed Memory Runtime – Unlike unmanaged C/C++, C#/VB.NET developers don’t have to worry about strictly controlling object lifetime. Like Java, the CLR has a garbage collector that automatically frees objects in the heap that leave scope. While this may seem minor to someone used to unmanaged runtimes, it has the extreme secondary advantage of discouraging the “black magic” of pointer arithmetic that is so common in C/C++.
• Platform Independence – Windows Vista and Windows 7 work differently from Windows XP. Windows 8 works still differently. Windows Mobile versions including Windows 8 Mobile work differently again. Different hardware, different architecture, different capabilities. While the target environment does still matter to a .NET developer, the amount of specialized knowledge is far reduced compared to what has to be known to build a compatible C/C++ program for all of these OSes. A C# dev gets a lot more for free.
• Web application support – I haven’t yet seen a client-facing, server-scripted web application written from the ground up in C++. The web server, sure, Apache, ISS, they all typically run against an unmanaged runtime for speed/efficiency reasons. However, C++ is not a language used for building web applications. C# is (as is Java). It was designed from the ground up to support the next generation of Microsoft’s ASP paradigm. This is code designed to run in a sandbox; which sandbox (the ASP.NET plugin to ISS or the “desktop” CLR) is relatively unimportant.
• Language/runtime independence – A C++ compiler takes C++ source code and produces assembly code for one processor architecture using one machine language. To support a different architecture and/or machine language, a completely new compiler must be written (and a completely new set of runtime libraries must be compiled). A C# compiler takes C# source code and produces CIL, which the hardware-specific JITer translates to machine code. The same JITer can translate any CIL program no matter what the source language (and there are several; C#, VB.NET, F#, and a host of “Iron” language ports like IronHaskell, IronRuby, IronLisp, etc). The same compiler can turn one language into CIL that any JITer can run, no matter the hardware. This reduces the amount of work that must be redone from scratch for every new language or platform supported by the .NET Framework.
• Focus on “correct” code – For C++ devs, there are a lot of “right” ways to do something, depending on what’s most important; memory efficiency, CPU efficiency, hardware independence, OS independence, etc. Code can look drastically different when each of these is the priority. C# was designed by a group that took to heart the conceptual lessons of Fowler and his colleagues (who were working to reform code design within the C++ community by teaching object-oriented principles to a community that largely moved up into it from C), as well as the practical lessons learned by the languages that came before (including Java, and its near-fanatical obedience to the almighty Object, when a good old C++-style function pointer would do the job much more cleanly and not be any less object-oriented).

For antitrust reasons, MS is careful not to be seen “interfering” too heavily in other major platforms like Android, Mac OSX/iOS and Linux; however, it does indeed have teams developing for all three of these platforms. There’s an MS-developed version of Office for OSX, there are numerous applications including Office interop apps for iOS and Android, Skype (now a Microsoft product) runs on Linux, and Microsoft has even been seen contributing to the Linux kernel (primarily in a virtualization mindset).

The Windows OS is available for different CPU types, today mostly x64, x86, Intel, ARM.

CIL/CLR is independent from that hardware platform – these differences are “abstracted away” by the IL execution environment. For example, a .NET assembly compiled for “any CPU” can typically executed on Win64 as a 64 bit process, and Win32 as a 32 bit process, without the need of providing different executables.

Moreeover, the CIL allows metadata to be stored in assemblies which is not easily possible with native DLLs (it is possible, of course, MS did this before with COM components, but that technology was never as easy to handle as .NET components). That makes creation of software components a hell lot simpler and is the foundation of reflection / introspection in all .NET languages.