> But seriously, state is inherent in most enterprise apps, which is to say, 95% of apps in existence.

That doesn't justify the claim that for most problems FP is poor; functional languages deal with mutable state, indeed, a big point of FP is that using it provides a way to cleanly divide pieces of code that deal with mutable state so that the presence of mutable state only complicates reasoning about those pieces of code that it inherently must complicate, rather than making the whole code base hard to reason about.

The lack of state in FP is a major myth. There's plenty of state, it just looks different than you're used to and, thanks to that, is far easier to reason about. It means that everyone who's first making the transition from imperative/OO to FP complains about it, but anyone who sticks around long enough to learn much anything besides "Hello World" learns quickly that there's really no problem.

State is inherent but loops where recursion helps are sadly in scarce supply in enterprise apps (at least the ones that I've seen). Many (most?) apps are pushing data around, many times strings, often from a database. Lots of if statements, fewer whiles. Recursion can help with the kinds of problems that one encounters dealing with these types of programs, but it's not necessary and I would say probably doesn't even make things easier.

And the overwhelming majority of those apps probably experienced a particularly nasty and expensive bug that was due to state (i.e. one that would have been very difficult or even impossible to replicate in a primarily functional environment).