FP is not lacking mutable state.
Mutable state is managed in "external dependencies". Your mutable state is in a datastore of sorts (whether it's in-memory, database or caching component). Data doesn't travel unsupervised, it's manipulated close to the source using a simple recipe: take state => pass it along functions as parameters => get the result back => store it (or transform it some more).
The manipulation of state is isolated and composed of clean transformations.
In OOP state travels in a bag of methods + data (the object) which can mutate itself at will to the point where you have sets of conventions telling you not to (immutability is nowadays as much of a pillar of OOP through DDD as polymorphism).
The core tenet of FP could be worded as "let data be data". Why attach method to data? A chair doesn't change itself, it doesn't change other chairs. For all intents and purposes, a chair is data (a set of parameters) that can be manipulated by external forces.