It's slower, with a bigger file size, and harder to develop for...but nerds who make $30,000 a year won't look down on you and say "you don't get it"!
Hmmm... a bit of a naive, if not short-sighted assessment. Most .Net developers are making anywhere between $30-$70 per hour depending upon their experience and role... And believe it or not, a vast majority of that money is earned on writing software that's conceptually quite a bit less complex than some 3d world builder gizmo.
There's a difference between "not getting it", and "not wanting to understand it". Those that are afraid of change, and complacent in their knowledge usually fall in the latter, and are the ones that are usually looked down upon by the nerds. :)
Time is money, either way you look at it. If you spend more development time on BETTER, FASTER software that people are willing to pay MORE for because it is GOOD, then you can make up for the cost of additional development time. With the smaller programmers schedules and quicker releases of bloated software, you are requiring customers to make up your smaller costs of development with larger costs of larger amounts of hardware required to run your bloated apps because you didn't want to do your job as throughly as you could have. It's a good thing that hardware does tend to get cheaper to make, otherwise using your logic, you would be out of business because your customers couldn't afford to run your software.
Interesting point if the real world worked this way, or if .Net's "bloat" was as significant as you're trying to make it out to be. As Craig pointed out, the most successful projects leverage what's available rather than re-inventing the wheel. Granted, there are times when what's available does warrant a "roll your own" implementation, but that's more the exception than the rule. By utilizing API's in the standard .Net library (and the vastness of available API's is astounding), you get all the benefits of using a software vendor's libraries, including updates and optimizations in later releases.
Moreover, the so-called bloat is an insignificant, yet necessary evolution of design on the levels of software, compilers and operating systems. .Net assemblies include management code to assist in garbage collection, type safety, configuration metadata, and debugging. If one can't see the value of this, you're probably not in the audience that .Net is targeting the most: those that have had to design/code/maintain an enterprise level application.
The BLOAT factor still exists because I haven't come across a .NET app YET that was as snappy as the Win32 equivalent.
This is a fine argument if the expectation is that we will always be in 32-bit operating systems.
Microsoft's motivation for creating .Net isn't just to kill off Java.
A side effect of abstracting the programs into a CPU/OS/environment agnostic intermediate language allows future operating systems to reduce the burden of backward compatability through emulation for applications leveraging IL.
Over time, you'll probably find that your Win32 applications created today will run slower on future MS operating systems, while .Net applications will run as fast or faster than the day they were created. To top it off, it won't matter what CPU those future operating systems target.
Why will they run slower? The same reason Win16 applications run slower on Win32. It will all have to be done through emulation. Win32 APIs and EXEs will have to be "virtualized" and wrapped in an assembly that sanitizes it to the agnostic nature of the operating system. This wrapping overhead will undoubtedly create slower running applications. Slow enough to be non-functional? I doubt it. Slow enough to be noticable? Probably if it's a game. Probably not if it's a word processor.
As Orca eluded to in an earlier response, today, it's somewhat of the reverse. Portions of .Net are "emulated" on top of Win32. As they (MS) make updates to .Net, these emulated bits get replaced. This is part of the reason .Net gets faster with each release.
VS Express is using 2.8mb of resources while running minimized. MaxEdit only uses 2Mb minimized. When I pulled up VStudio, it took a whopping 26Mb of RAM while swapping back in. MaxEdit only took 3 more Mb to come back alive.
Apples to oranges. Have you compared the features of the IDEs? Considering Studio's IDE is about a billion times richer... In light of your other analysis, if MaxEdit was a clone of Studio's IDE, wouldn't it be safe to say that it would have similar performance issues?
Anyway.. looks like you're sort of seeing the reason why so many people are excited about it. Welcome to the collective :)