Such as? Ok, so you get better multithreaded behaviour but now you're copying state all the time and having to thread it though all your functions. Sometimes just updating state is the right thing to do.
Personally, I think a good tradeoff is immutable data but mutable references.
If you have a function that moves a player in a game such as movePlayer :: PlayerState -> PlayerState, you know that it only changes the state of this player, and nothing else. In an OO language you would do something like player.doUpdate(), which has absolutely no guarantees.
Plus there are many facilities available to deal with threading and hiding state.
This gets ugly when the state of every actor can potentially affect the state of every other actor, though. This is pretty common in games.
That's the main point the linked article is making.
My point, instead, was that FP does not break down when things get ugly; on the contrary, it gives much stronger guarantees on correctness. Of course, it takes effort to express the problem in the more restrictive functional paradigm.