简单地说：是因为该语言的设计者决定不使用。
基本上，.NET和Java的设计者不使用多继承（MI），是因为他们认为给语言加上多继承获得的好处较少，抵不上因此增加的复杂性。
1、不同的语言对于多继承如何工作实际上有不同的期望。比如说，在冲突时基类如何合并或处理冗余。在CLR中实现多继承之前，我们需要查看一下所有其他的语言，看看一些共通的概念，并在一种语言-中立的方式来表示它们。我们还需要决定多继承是否应存在 于CLS，而这对于不想要这个概念的语言（比如说可能有VB.NET）。当然，这本是公共语言运行时的分内之事，然而我们没有找到足够的时间为此来做。
2、多继承真正合适的地方实际上很少。在很多情况下，多接口实现都可以做这个事。在其他情况下，你可以使用封装和委托。假如我们添加一个稍微不同的构造器，如mixins，会更强大吗？
3、多继承给实现增加了很多的复杂性。这个复杂性影响了类型转换，布局，字段访问，序列化，身份比较，可验证，反射，泛型以及可能还有很多别的地方。
原文:
The short answer is: because the language designers decided not to.
Basically, it seemed that both the .NET and Java designers did not allow multiple inheritance because they reasoned that adding MI added too much complexity to the languages while providing too little benefit.
-
Different languages actually have different expectations for how MI works. For example, how conflicts are resolved and whether duplicate bases are merged or redundant. Before we can implement MI in the CLR, we have to do a survey of all the languages, figure out the common concepts, and decide how to express them in a language-neutral manner. We would also have to decide whether MI belongs in the CLS and what this would mean for languages that don't want this concept (presumably VB.NET, for example). Of course, that's the business we are in as a common language runtime, but we haven't got around to doing it for MI yet.
-
The number of places where MI is truly appropriate is actually quite small. In many cases, multiple interface inheritance can get the job done instead. In other cases, you may be able to use encapsulation and delegation. If we were to add a slightly different construct, like mixins, would that actually be more powerful?
-
Multiple implementation inheritance injects a lot of complexity into the implementation. This complexity impacts casting, layout, dispatch, field access, serialization, identity comparisons, verifiability, reflection, generics, and probably lots of other places.
引自：http://stackoverflow.com/questions/995255/why-is-multiple-inheritance-not-allowed-in-java-or-c