Around 3-4 sounds about right for an application, anything beyond that could probably be refactored. The exception to that would be if you're designing a framework, where it could be very useful to break that rule to provide a cleaner API.

This. There are some problems with object-oriented as a paradigm, and composition is an interesting alternative that has a lot of benefits if your type system can back it up. No individual paradigm makes 'the right' compromises in every situation--even as I'm driving toward protocol-based composition as my primary tool in Swift, I still am very glad to have good ol' classes around for a handful of situations.

I think that you should consider that, anywhere you have an inheritance tree deeper than three or four, you should ask yourself if you're encapsulating your variation correctly. Ideally, if you have fourth and fifth derivative objects, then they should spend most of their lives being treated as anonymous concrete instances of some superclass at the third or fourth level.

Deep inheritance usually means you are inheriting along multiple "axes" of variability. In a language without interfaces or multiple inheritance (and sometimes even in those) you should model multi-dimensional objects with composition.

There are exceptions of course, especially if you are making an extensible framework.