I think OOP is taught somewhat wrong because people will dwell on contrived examples of inheritance when its real value as a paradigm is coupling state with functions. What we've learned from FP is immutability is easier to reason about, but when it isn't is when OOP shines because it gives you a sane way for managing state.
I think I ended up going with a Player API with tapes, records, CDs etc. Some could skip, others only fast-forward. I was still unhappy with it, but it was better than most examples.
I like to point folks at writing an IntelliJ plugin. I find that some of the best architected OOP programs become nothing but a collection of plugin interfaces and base classes.
But you really need to understand "is a" vs "has a", not burn your base class, let architecture emerge following the rule of 3, rather than quickly jumping on the wrong abstraction to fight duplication.
Sandi Metz really says it better than I can: https://www.youtube.com/watch?v=8bZh5LMaSmE
The downside to them is that there is that the base class in the inheritance chain (BaseModel -> Model -> YourModel) has some magic that is difficult to reason about (the upside being the other side of that same token!). Thankfully, it's reliable and there's rare occasion to dive in.
Maybe this is a me problem. I don't know how to make a nice abstraction layer like that without inheritance, so I think inheritance is sometimes the answer.
When used in that context, it's truly excellent. I suspect your example from Django fits this pretty well. But it's far too easy to abuse for general code reuse, which is a deep and alluring tar pit.