I usually go even further and think of mixins as copy-pasted code. What I observed on many teams is that people look at a huge class and think “wow, this is bad, let’s make it shorter” - split it up into a bunch of mixins, and “hey, now they’re all short and awesome”.
But they don’t solve a problem of bad OO design this way - just hide it by sweeping it under the rug of multiple files. If you look at a class as an entity, nothing changed in it after the split - it’s still the same huge ugly class.
I’ve been fortunate to work on a few long-term projects (over 5 years of constant development and maintenance), and mixins never worked out well, but just ended up bringing a mess. This is why the same patterns now popping up in JS land (such as stamps) do bug me a lot, as they look like the same bad idea repeated all over again.
The thing that did work, though, is what @mario says - identifying units of reuse or separate domain entities, and splitting a huge classes into many composed objects. The small ones are also much easier to test - less behaviour and edge cases to cover, smaller setup, faster tests overall, and then just an integration test over the whole feature to make sure everything plays nicely together.
As an aside, I recently came across a research paper on this very topic - Traits: A Mechanism for Fine-Grained Reuse, where authors argue against mixins and multiple inheritance, but it favour of traits, which are different from mixins as being stateless and only defining methods with explicit conflict resolution mechanisms. Scala comes to mind as an obvious example of this implemented in today’s world, but I haven’t done enough of it to really have an informed opinion - I’d be very interested to hear from someone with more experience here.