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.