(In Eclipse, you can select a member variable of a class, and automatically generate delegates to it)

Implementation inheritance is not a core pillar of OO. Polymorphic behaviour depends on type inheritance, not implementation inheritance. Implementation inheritance provides one form of aggregation of behaviour; the other being aggregation via composition (e.g. delegation).

When you have classes with mostly similar behaviour, but some differences, composition gets a bit painful. You end up delegating most of the class, but leaving a little bit. In these scenarios, implementation inheritance makes a lot of sense. In general, if you are overriding less than about half of the behaviour of the parent, stick with implementation.

The real issue (and the cause of the abuse) is classes that have too much behaviour. Too much behaviour makes composition too painful (too many methods to delegate), but makes an inheritance hierarchy too convulted.

To paraphrase hitchhikers guide to the galaxy:

Developers must not use implementation inheritence ever unless one of the following is true:
1) Their life depends on them using it
2) Their life would otherwise depend on it if they weren’t able to use it
3) They really really want to.

VB (pre .Net) had only interface inheritance (not sure about VB.Net) – I suppose that was a good thing, as otherwise it would have been like a kid with a new toy, as it was a lot of peoples only experience with OO in corporate development.