1) if there are people who come back to using inheritance AFTER doing programming with typed systems that support typeclasses (like Haskell). If so, would you able to articulate why you think inheritance is still a superior pattern?
2) if there were any use cases that could be solved using inheritance that could not be solved more elegantly without it?
There are behavior mixins, that you can look at Django views as an example. There are interface implementations when you want to have a few almost complete standard ones.
Both are cumbersome to implement on Haskell. If you make sure to not use any widely used class, you can hack them out of some sets of hierarchical type classes with possible some overlapping. But leaving half-done stuff at your API to be filled by client code is never pretty there.
Overloading not inheritance. It is closer to the notion of interfaces in traditional OO languages, but it's a mistake to confuse interface implementation as inheritance.
This is a common problem with traditional OO languages: they conflate inheritance with subtyping, ie. "Y inherits the behaviour of X" is not always the same as "Y can be used anywhere an X can be used" (subtyping). C++ has "private inheritance" to separate these notions now, but it's a kludge from this initial design mistake.
So type classes use subtyping, but not inheritance. Interface implementation is also closer to subtyping than inheritance.
When you separate data from functionality into separate "things", composing things out of them becomes nicer.
I'm not a Haskell programmer, but AFAIK type classes contain functionality, NOT data (state).
Example of what I'm talking about: Clojure's Protocols.