Regarding #1 - This isn't just applicable to component-based game entity systems, this is a fundamental teaching of OOP!
There's a ton of writing on composition vs inheritance, and the general rule of thumb is that you should default to composition, and use inheritance only when you have to (and only where you satisfy the promises that an "is a" relationship implies, such as the LSP).
Game component/entity systems are just a fancy way of making use of the software engineering principle of composition.

Excessive inheritance usage was popular in games in the 90's because most people were new to OOP and/or misunderstood OOP in the 90's
When you're new to OOP, it feels very natural to use inheritance to solve every problem, but there's often an alternative.

N.B. many great games were/are made using this coding style, so while being wrong IMHO, it obviously still works.

I've been experimenting with both in my own game and noticed that the main difference is that inheritance-based system tends to be far more "hard-coded" whereas a component-based one tends towards being "soft-coded." As far as pure DATA it doesn't matter that much, but it plays into LOGIC and you need to ask yourself, who do you want designing it - the programmers or the designers? The latter approach is increasingly popular because, much like contemporary games that rely on what-you-see-is-what-you-get editors and visual script/material systems, are all about empowering the designers so they can make and prototype without having to go through the programmers.

While it may seem that a component, designer-friendly component system would be the better choice, it does come at a price. Firstly, you will actually need a framework for handling logic by designers somehow. After all, they may assing whatever properties they want to entity (PhysicalBody, PartOfAFaction, InventoryOwner etc.), which basically destroys the concept of a "class." Think about it. You no longer have a "class CLever" but merely an entity with some CAnimatedModelComponent and CUsable, which triggers the animation and opens some door.

Either you have some flexible scripting framework that you can attach to the OnUse Event, or you hardocde a CUsableDoorOpeningSwitch that also requires a CAnimatedModelComponent to be placed on the entity... but at that point it would have actually been easier to simply make a CLeverEntity with AnimatedModel and TargetDoor properties.

The second problem is that it basically becomes a "weakly typed entity system." So it's great for fast prototyping, but is VERY prone to bugs. Suddenly the designers need to make sure the entity has all the right components that interact properly or unexpected errors will pop up. Worse yet, it is much harder to debug or account for those edge-case scenarios, and many of them wont pop up unless you do a lot of QnA.

In my experience, a component system is far more flexible and faster when set up right; but setting it up requires a lot more work and maintenance, and lack of proper support results in hard-coding very specific components that only apply to very specific types of entities, in which case you would be better off with an inheritance base system from the start.

In a nutshell: Honestly, consider what kind of a game you have, and what kind of entities you need, and go from there. If you dont need too many, inheritance is better. If you need a lot of rapid prototyping, component is the way to go.

Interesting links, the GDC and the video. I think there's also room for a mixed approach, especially when it comes to performance. You could do it by distinguishing between "engine" components (graphics, audio, physics etc.) and "gameplay" components (Usable, Inventory, Health, etc.) since the former often require greater optimizations and are less likely to be be rapidly prototyped by designers, whereas "gameplay" components will be constantly swapped around and readjusted.

The GDC mentions that RenderBehavior and PhysicsBehavior as attachable to GameObjects, right next to MoverBehavior or probably things like TriggerBehavior or InventoryBehavior. But what if, instead, you hard-coded that all GameObjects must have the Render/Physics/Audio components (or NULLs) and keep a free list of Gameplay Components? This way you can use direct function calls and make assumptions when it comes to rendering, physics and AI (as it relies on world visible/physical data), but still allow for flexible gameplay prototyping with messages/attributes between components.

You could even go ahead and make a few "base" GameObjects that force certain components; so a CCharacter would always have a RenderableBehavior and CRagDoll, a CProp would always have a CRenderalbe and CPhysics etc. While this does bring back some of the inheritance issues, if you design it right, it could potentially make engine-code much more cleanly separated from Gameplay/AI/Scripting code, and allow for necessary optimizations.