I think a lot of the "religious" feeling I get from FP advocates is the constant focus on purity and the "No, you AREN'T DOING IT RIGHT!!!" kinds of tantrums. You HAVE to understand the nuance. You HAVE to participate in these strange little paradigms that esoteric thinkers have come up with. Ultimately, I think of FP languages like Haskell as playgrounds to pilot bleeding-edge ideas before the best ideas get incorporated into languages that are widely used in production.
Ultimately, some real-world processes are just procedural, and procedural languages are easier to apply to them. When it comes to callbacks, mapping functions to a list, etc., it's pretty clear to me that FP paradigms are superior.
In other words, I think it's part fad/religion, but as with anything, you can learn from it and take the good parts.
Most languages have already taken the good parts. We barely even consider them a "FP thing" anymore. Callbacks and map() are just things you can do in most languages.
What remains when people advocate for more FP is the more esoteric stuff. (And non-nullability, which inexplicably gets associated with FP surprisingly often despite being orthogonal to everything else in the paradigm.)
Problem is, it's hard to distinguish the chaff from the wheat. A lot of practices that advertised themselves as "the way of the future" and most of them faded into nothingness.
At some point people try to save time and stick with practices that stand the test of time.
Ultimately, some real-world processes are just procedural, and procedural languages are easier to apply to them. When it comes to callbacks, mapping functions to a list, etc., it's pretty clear to me that FP paradigms are superior.
In other words, I think it's part fad/religion, but as with anything, you can learn from it and take the good parts.