A Little Background
Prior to .NET I built Windows applications in Visual C++ 6.0. I still believe C++ has its advantages. It is very fast at simple math operations as it compiles down very well. Because of that it was my language of choice for the OpenGL programs I used to write at www.gldomain.com. Some of those programs had loops in them which handled millions of math operations per second. If that code wasn't executed fast enough, you'd see the direct results in the form of a slow or choppy frame rate. But as I'll expand on later, C++ development has one big disadvantage.
Coming to Accept .NET as a Viable Platform
Some people are still apprehensive about developing Windows applications in .NET because it requires users to also have the .NET Framework on their computer. It's certainly a valid concern. Of course, any programming architecture you choose is going to require certain dependencies. I suppose the adoption rate of those dependencies is the big defining factor. These days I believe Adobe (formerly Macromedia) Flash is used by over 90% of all users browsing the web. Then DirectX is required for basically any video game worth playing. And then at a deeper level, Windows Installer is required to install most Windows applications. All of these components are so common by now that I don't hear much complaint about the need to install them.
Of course, Microsoft has included .NET in Windows distributions since Windows XP SP1. And they push it out in Microsoft Updates. So its adoption rate is quite good as well. Unfortunately, the simple fact is that not everyone is going to have the latest version because not everyone keeps their computer up-to-date. But Microsoft is pushing .NET for a good reason. It is an extremely well done platform to build upon.
.NET Stability
One of the biggest changes when using the .NET Framework is managed code. Managed code is like a virtual space where the code will run without affecting outside applications. Because of this, applications that run on the .NET platform are less likely to crash, and it is virtually impossible (or extremely rare) for a pure .NET application to take down the system.
.NET Speed
.NET performance is quite good as a whole if you use its features wisely. The one bottleneck that remains is math operations in VB or C#. That's why you're not going to see many video games being built in VB.NET. But performance tuning is all about finding and eliminating bottlenecks. And one thing you can do is include unmanaged C++ in your .NET application for any math-intensive sections or loops in your code. If you do this well you can have your cake and eat it too. You can get the advantage of stability and rapid development time of a .NET application with the speed of a C++ application.
.NET Simplicity
From my point of view .NET makes a lot of things easier which is the primary reason why I use it. It allows me to focus a little more on building the functionality I want and a little less on the variances in Windows installations and computer hardware differences.
My Real World .NET Example
Going back to C++, I must say that in my opinion C++ is too much of a low-level language for most large business applications. In my eyes that's its disadvantage and that's the problem I ran into with one application in particular that was originally developed in India. It was a simple document management system of sorts with a nice wizard-like interview process to help you fill out documents. It really shouldn't be too complicated when you think about it. But the sheer amount of C++ code needed to write it was insane.
In 2004 I was given the task to take over the development and support of this application. And after about a year of that I ran into a compatibility issue when Vista was coming out. At that point I was faced with a decision. Either I needed to hunt down the problem in hundreds of thousands of lines of mostly unfamiliar code, or scrap the C++ and rebuild it in .NET. Well, I rewrote the whole thing in VB.NET 2.0. It turned out to be the right decision as I was able to recreate its functionality in a couple months. And in the end I probably wrote only about 1/10th the amount of code of the original. Furthermore, I was able to make certain enhancements, and it's been virtually problem-free and hasn't needed any changes at all in the past couple years.