Implementation inheritance is indeed problematic, no matter how it's used. The defining feature of implementation inheritance is that any code, relating to any class in the hierarchy, can rely on methods that may then be overridden in unpredictable ways further down in the hierarchy. If you don't need or expect this behavior, you can use composition and delegation instead - which come with a far simpler semantics and do a way better job of preserving modularity.
Implementation inheritance is absolutely no problem within a project or component that entirely controls both base and derived classes, where it amounts to, simply, a notational convenience. It is not, then, a "good OO design"; but there is nothing sacred about OO. Ultimately, any combination of well-specified mechanisms may be correctly used to achieve an elegant design, regardless of formal architectural conventions. The reason a feature was introduced into a language has no necessary connection to reasons for using it.
Implementation inheritance is a problem when crossing organizational boundaries, as reasonable changes upstream can impact correctness downstream.
Ultimately, there is no substitute for taste. Substituting fetishism produces unfortunate results.
