Since you asked why C# did it this way, it's best to ask the C# creators. Anders Hejlsberg, the lead architect for C#, answered why they chose not to go with virtual by default (as in Java) in an [interview][1], pertinent snippets are below.

Keep in mind that Java has virtual by default with the [final][2] keyword to mark a method as non-virtual. Still two concepts to learn, but many folks do not know about the final keyword or don't use proactively. C# forces one to use virtual and new/override to consciously make those decisions.

> There are several reasons. One is **performance**. We can observe that as
> people write code in Java, they forget to mark their methods final.
> Therefore, those methods are virtual. Because they're virtual, they
> don't perform as well. There's just performance overhead associated
> with being a virtual method. That's one issue. 
> 
> A more important issue is **versioning**. There are two schools of thought
> about virtual methods. The academic school of thought says,
> "Everything should be virtual, because I might want to override it
> someday." The pragmatic school of thought, which comes from building
> real applications that run in the real world, says, "We've got to be
> real careful about what we make virtual." 
> 
> When we make something virtual in a platform, we're making an awful
> lot of promises about how it evolves in the future. For a non-virtual
> method, we promise that when you call this method, x and y will
> happen. When we publish a virtual method in an API, we not only
> promise that when you call this method, x and y will happen. We also
> promise that when you override this method, we will call it in this
> particular sequence with regard to these other ones and the state will
> be in this and that invariant. 
> 
> Every time you say virtual in an API, you are creating a call back
> hook. As an OS or API framework designer, you've got to be real
> careful about that. You don't want users overriding and hooking at any
> arbitrary point in an API, because you cannot necessarily make those
> promises. And people may not fully understand the promises they are
> making when they make something virtual.

The interview has more discussion about how developers think about class inheritance design, and how that led to their decision.

  [1]: http://www.artima.com/intv/nonvirtual.html
  [2]: http://en.wikipedia.org/wiki/Final_%28Java%29