bThe Slashdot version of this story has the headline: "C# Memory Leak Torpedoed Princeton's DARPA Chances" This is sort of accurate. The issue isn't with Microsoft's implementation of C# or runtime, but with Princeton's code.
Bryan Cattle has a good writeup of what happened. Essentially, objects they thought were getting garbage collected were not because there were still references held to them. In this case the objects were registered as subscribers to events. By forgetting to unsubscribe the objects when they were done with them, they ended up with a 'memory leak'.
They eventually tracked down the problem with the use of the ANTS profiler. This is a great example of why it is important to really understand how the 'magic' parts work, and to verify that they are behaving as you expect. In this case, by not carefully tracking all the references to these commonly created objects, they ran into big problems.
Every 'real' developer should be proficient with profilers and use them as part of the development cycle to verify the system is behaving as expected. You won't necessarily catch every issue, but you'll have a lot better understanding of how things really work.
I find today that with the current generation of development tools, developers can function without really understanding what their code is doing. This usually works fine for small and mid-sized web or client applications, but can really cause problems with a project that needs to scale or function for long periods of time.