The question is pretty self explaining: doesn't multiple inheritance solve all the problems that entity systems also solve?
I just remembered a term called "multiple inheritance", and that seems to solve a lot of bloating problems that classical inheritance imposed.
No, multiple inheritance does not solve all the same problems that entity systems do: entity systems and multiple inheritance are two very different things. You can build an entity system with or without multiple inheritance and similarly you can utilize multiple inheritance without building an entity system.
Traditionally, component-focused entity systems are developed because of a desire to move away from heavy inheritance in any form, aiming instead for composition. There is sufficient literature and discussion elsewhere on this adage, for example on programmers SE or SO itself, and it the larger question of why to prefer composition is sort of off-topic for game development. In short, however, it's an approach that tends to lend itself to improved mutability and maintainability.
Josh's answer is awesome, but I'd like to add:
One of the coolest features of Entity/Component is the data-driven way in which every "thing" in your game is created and managed. From what I've seen, once you have a nice library of component types and systems created, you can build just about anything with minimal code modifications. (Note: minimal != 0)
By defining your game in terms of behavior, and giving yourself the ability to modify those behaviors on the fly - at runtime, during initialization by loading them from a script or database, etc. - you open up an entire world of new possibilities. Want to see why your shadows don't land where you'd expect? Add a camera/POV component to your light.
Entity/component lets you build anything you want, as long as you've created the blocks.
Also, multiple inheritance causes the same problem as single inheritance. When you add an attribute or behavior in the hierarchy, it propagates. As long as you're making deep hierarchies, you'll run into situations where you're carrying unnecessary weight, duplicating code, or resolving conflicts. Most of that can be avoided when you imagine your game as data.
I've just started playing with this in the past few weeks, but I'm impressed at how simple things have become. It's not a silver bullet - I've run across a few cases where attaching a lambda to a component was the cleanest and most expedient way to solve a problem - but it's a pretty great pattern, if you can call it that.
On a slightly related note: one of the big, boring maintenance generators in data-centric applications (websites, etc.) is mapping hierarchical objects into relational databases. We've got lots of nifty solutions around, but they're ultimately all hacks designed to flatten hierarchies. Instead of building your model so that it serves the purpose of the application, you wind up compromising between an effective hierarchy and a logical relational representation. I've been toying with the idea of rebuilding a pretty large hierarchy in one of my apps as an entity/component system - ditch the hierarchy and make the database the Gold Standard for the rest of the implementation - and it's promising.
When you integrate capabilities like dynamic code generation/code caching that can address performance issues, you wind up with a fast, flexible, logical architecture that might just realize the reusable code goal of OOP in a much, much better way.
