In theory, writing in a functional language that allows only "pure" functions (aka. functions w.o. side effects), makes it easier to control state.

In practice, side effects exists and are required for programs to do anything useful.

In my opinion, one mistake of many purely functional languages was to be so focused on this purity, that it made it needlessly hard to write useful code in them, especially for people coming from an imperative/procedural/oop style of doing things. And you need these people if you want your method to gain traction, because the vast majority of code written, is imperative.

The irony is, that FP could probably have had a lot more success if it didn't clamour on about pure functions so much, and was less focused on implementations (aka. languages) than on methodology (aka. coding style) Because it is perfectly possible to write pure functions in most languages, including OOP language, even if those functions are not "pure" internally, or are not "pure" all the time and under all circumstances.

And yes, doing so has really nice advantages. I have refactored quite alot of codebases into using a more functional approach, and what I found was that this makes it harder to introduce bugs, makes it easier to track bugs, and makes it easier to reason about my code.

So yeah, functional programming, used if and where it makes sense, does work, and is useful.