This article is just not very good, the author keeps talking about a zillion different things without really focusing on the actual, underlying issues. But one thing it does say right away is that mutable state is not a problem as far as it goes, what's problematic is mutability plus promiscuous sharing. This is what makes it unfeasible to reason about what the code is doing.

Similarly, encapsulation (bundling code and data) definitely has its uses - in preserving class-wide invariants, or in providing a "common" interface that makes it possible to disregard the inner workings of some data structure, and interact with it in a way that's not dependent on the implementation. But in practice, implementation inheritance in OOP often encourages what amounts to breaking encapsulation and making it possible to violate class invariants, all in search of some dubious "code reuse". If you can't express your desired code reuse pattern via some combination of simple interface inheritance, delegation and dispatch over "sealed", non-extensible variants (the mechanisms that plain old composition/FP gives you) there are probably some underlying problems with it that you haven't thought through.

Of course the standards of programming improve continuously over time. Even FP and broadly "FP-like" programming is not what it was in the 1980s, and some of that progress was brought (if perhaps incidentally!) by OOP languages. This is to be expected!