It seems to me that a new generation of developers are simply rejecting oo-paradigms because they are oo, without an in-depth analysis.
I agree with the general consensus that oo inheritance hierarchies of the past became too deep and were overwhelming, but subtyping has a place.
Because interfaces are stateless, you generally cannot completely implement required interface functionality without wiring them up to each individual object, resulting in a lot of boilerplate code repetition.
This is exacerbated in GUI programming, for example, where subtyping makes a lot of sense (and doesn't devolve into Animal -> Rabbit nonsense).
With subtyping, you can take an object that is 95% of another object and just override where necessary.
I also don't believe composition provides the same level of encapsulation that can be achieved through traditional class-based oo. There seems to be this prevailing view that oo is all about inheritance, when the truth is that oo was really about encapsulation and isolation. You only expose what you need to, and objects (whether they be classes or structs or whatever) can be built and tested without fear of code collisions or meddling from the outside view.
I will concede that interfaces can and do provide a level of encapsulation, but in practice, it's just clunky.
Just look at some Rust objects and the sheer number of traits that they must be aware of and implement by hand. It's piecemeal when it could be one and done.
And please understand, I'm not talking about "...in the beginning there was a GObject, and that GObject bequeathed to...and..."