.NET memory management (and ghosts from the past)

Channel9 of Microsoft published a two-part interview with Jason Zander, the Product Unit Manager for CLR. The half-hour discussion revolved around most of the possible .NET-related topics, including an interesting and insightful overview of .NET overall structure. Without rehashing everything said on the interview (part 1, part 2), a couple of performance-related things are worth a note.
Deterministic finalization was just quickly mentioned in the video, but the issue was again picked up in the comments. For those of you who don't know, deterministic finalization is the ability to exactly define when the destruction of an object takes place. This feature is missing in .NET (where the garbage collector finalizes the objects at some point of time), something that caused real panic and anger at one time, especially since people with C++ and VB backgrounds were so used to it.
The classic Brian Harry Manifesto on Deterministic Finalization was mentioned again. It had been a couple of years since I last read that – but it's still great. I mean, even if you don't know that much about reference counting or tracing, you will see a host of problems in a totally different light after reading that. But almost as much fun as Brian's posting are the replies to it (follow the link above and keep clicking "Next in topic").
For example, Brian's "We feel that it is very important to solve the cycle problem without forcing programmers to understand, track down and design around these complex data structure problems." got quickly answered with "The game's over if people are being shielded from having to actually design their software". Further down the thread, Microsoft's approach to .NET memory management was labeled as 'hand-holding, design-free "programming"'.
Later on, somebody says "It's downright *laughable* that Microsoft is worried about performance when their target is the internet!" Allright, that's the spot when at the latest you're going to have to smile. All of this took place in October 2000, only a bit more than four years ago. And what do we have now? Two of the foremost modern programming platforms (Java and .NET) are both based on garbage collection with a non-deterministic finalization scheme. Second, the performance and the Internet is an everyday challenge now, one that many people worry about. Not just network throughput, but the scalability of ASP.NET applications, Web Service endpoints and whatnot.
I won't spoil the fun of reading the thread by quoting more – there are some real gems of human arrogance down there. Sure, not everybody will ever pick up .NET or Java, and some programming tasks are still left to be done with C++. But still, how far down the "New patterns suck" road can you go? It's a pleasure to realize how much less tech-oriented programming tasks are today. I mean, creating enterprise business applications is hard enough as it is, even without worrying about cyclic GC issues or C++ style memory management. I'd much rather spend my time doing class diagrams in Visio than crafting elaborate refcounting architectures.