简短的答案是：因为语言设计师决定不这样做。

基本上，.NET和Java设计器似乎都不允许多重继承，因为他们认为添加MI会增加语言的复杂性，而带来的好处却很少。

要获得更有趣和深入的阅读，Web上提供了一些文章，并对一些语言设计师进行了采访。例如，对于.NET，克里斯·布鲁姆（Chris Brumme）（曾在CLR的MS上工作）解释了他们决定不这样做的原因：

实际上，对于MI的工作方式，不同的语言有不同的期望。例如，如何解决冲突以及重复的碱基是合并的还是冗余的。在CLR中实现MI之前，我们必须对所有语言进行调查，弄清楚常见的概念，并决定如何以与语言无关的方式来表达它们。我们还必须确定MI是否属于CLS，以及对于不希望使用此概念的语言（例如，大概是VB.NET）意味着什么。当然，这是我们作为公共语言运行时所从事的业务，但是我们还没有为MI做这件事。

实际上，真正适合使用MI的地方数量很少。在许多情况下，多接口继承可以代替工作。在其他情况下，你可能可以使用封装和委派。如果我们要添加一个稍微不同的结构（如mixin），实际上会更强大吗？

多重实现继承为实现注入了很多复杂性。这种复杂性会影响投射，布局，调度，现场访问，序列化，身份比较，可验证性，反射，泛型以及可能还有许多其他地方。

忽略Java语言的多重继承的原因主要来自“简单，面向对象和熟悉的”目标。作为一种简单的语言，Java的创建者想要一种大多数开发人员无需大量培训即可掌握的语言。为此，他们努力使该语言尽可能地类似于C （熟悉），而又不承担C 不必要的复杂性（简单）。

在设计人员看来，多重继承会带来更多的问题和混乱，而这并不能解决。因此，他们削减了语言的多重继承（就像削减了运算符的重载一样）。设计师丰富的C ++经验告诉他们，多重继承根本不值得头疼。