I'm not necessarily going to go to bat for the specific encoding of OOP Haskell in the linked post, but in general, there are problems where objects are a good fit. William Cook (in the paper On Understanding Data Abstraction, Revisited) claims that the key feature of objects is that they are defined in terms of an external interface whose internals are hidden: this captures, for example, SmallTalk-style message sends and duck typing as well as the information-hiding found in languages like C++ or Java. One way of encoding this idea into Haskell is with records of functions: to give a tiny example, a set type can be represented as

    data Set a = Set { contains :: a -> Bool }

which leaves the actual structure of the set undefined. This means you can use a variety of methods 'under the surface' to compute set membership and the external interface can be identical and compatible:

    emptySet = Set { contains = \_ -> False }
    singletonSet x = Set { contains = \y -> x == y }
    union l r = Set { contains = \y -> contains l y && contains r y }
    fromList lst = Set { contains = \y -> y `elem` lst }

And while this example is a bit trivial, this pattern is invaluable for writing things that OOP can traditionally excel at, like writing GUIs or certain kinds of video games where you want to bundle heterogeneous behavior into a single package:

    data GameObject = GameObject
      { render :: Pos -> GraphicsContext -> IO ()
      , currentPosition :: Pos
      , setPosition :: Pos -> GameObject
      }

Of course, this is only one (significantly simpler!) encoding of OOP, and it might not be one that you think captures the key ideas of objects, but to the degree that it is it demonstrates that ideas which are common in OOP (like information-hiding behind an interface) can still be useful in Haskell when judiciously applied in the right context.

The paper I cited can be read here, which has more details: https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf

There used to be a object Haskell, with a more classic type class model than the current trait-like model.

It looked like mathier version of OCaml written classic object oriented way, not half bad. Didn't get traction. It was mostly defined in standard Haskell.

Just because you can, doesn't mean you should.