My main point in support of OOP is that OOP doesn't prevent you from making all your 'movable state' into raw messages. Properly encapsulated instance state is actually not dangerous nor unpredictable. What I like about OOP is that it offers some additional benefits in terms of high cohesion and loose coupling because co-locating logic with related state helps to write high cohesion, loosely coupled modules. It allows my messages and function/method signatures to be even leaner than FP allows.
If you want to catch a taxi to the airport, FP still demands that you bring a jerrycan of fuel to give to your taxi driver, the only restriction is that he cannot alter it (no mutations). This has some benefits if you then plan to re-use that same jerrycan of fuel for your airplane too... But is that how the world works?
Indeed if you pass by value/use immutability where feasible, you already avoid most of the issues I’m warning against, so it sounds like you found a sensible way to apply it while avoiding the pitfalls.
> If I have to give a taxi driver a jerrycan full of petrol, that's the definition of a leaky abstraction... Possibly literally in this case.
:D