I see the benefits of making objects in my program immutable. When I am really deeply thinking about a good design for my application I often naturally arrive at many of my objects being immutable. It often comes to the point where I would like to have all my objects immutable. However, this drives my code more and more to the functional paradigm and this progression always happens:

1. I start needing persistent (in the functional sense) data structures like lists, maps etc.
2. It is extremely inconvenient to work with cross references (e.g. tree node referencing its children while children referencing their parents) which makes me not use them cross references at all, which again makes my data structures and code more functional.
3. Inheritance stops to make any sense and I start to use composition instead.
4. The whole basic ideas of OOP like encapsulation start to fall apart and my objects start to look like functions.

At this point I am practically using nothing from the OOP paradigm anymore and can just switch to a purely functional language. Thus my question: is there a consistent approach to good immutable OOP design or is it always the case that when you take the immutable idea to its fullest potential, you always and up programming in a functional language not needing anything from the OOP world anymore? Are there any good guidelines to decide which classes should by immutable and which should remain mutable to ensure that OOP does not fall apart?