Mathematician: primarily concerned with numbers and the stateless universe of mathematical objects. Primary audience for functional programming.
Roboticist: because "control systems engineer" doesn't trip off the tongue. Primarily concerned with physical machinery. Trained on things like Kalman filters and lift controller state machines. Would like the certainty of functional programming but tends to write sphagetti assembler instead in order to reduce interrupt latency.
Plumber: someone who would like to build a system by joining together parts. Perpetually disappointed by how hard this is. Labview is the archetype system here, although a lot of web framework/"stack" talk shows this kind of thinking.
Bureaucrat: someone for whom the records are the primary concern. Tends to build systems which look like CRUD but actually embed a complex workflow which is divided between humans and computers.
The thing is, only the mathematicians are really comfortable hiding all the state in the world behind monads. "Plumbers" might be the next easily persuadable, as FRP maps quite well to this way of thinking, as does map/reduce. But there isn't quite the tooling to enable building software out of pieces joined by pipes.
In the electronic and bureaucratic control systems, changing state is the point of the program. The thinking revolves around state, when it should be updated, and what it should be updated to. Stuffing this all behind a monad results in unnatural-feeling programs. There's a hybrid point where you have a "state" part of the program and a pile of "next state" logic which is basically the only way to write Verilog/VHDL - and it's hard to learn and not so naturally expressive.
Perhaps the way in is something like C++'s "const": you take a language that isn't functional and mark parts of your code as non-state-modifying, making it easier to subject them to formal reasoning.