I think I can relate. I'm a pragmatist (I think anyway), and it was tough to "get" the point of FP just from reading about it, and sometimes I think the proponents can unwittingly make it sound more complicated and wondrous and less accessible since from an outside perspective the terminology seems like a pile of academic buzzwords (it's not, just how anything specialised can look from the outside).

It took a while of actually using some FP patterns for a couple of things to sink in. First, that I'd already been using these patterns in an ad-hoc way, I just didn't have the terminology for it, and second was realising just how repetitive these patterns were in my work. A lot of the code I wrote would either iterate over collections to do stuff to the contents / build a modified collection (map), or iterate a collection and determine something about the contents, like does the user have product x in their cart, or something (reduce).

These days I find code more readable when it uses mapping / reduction and other FP patterns, it's not so much that there's less boilerplate (maybe a couple of lines, nothing drastic), but the grammar itself expresses meaning, I don't have to trace through an entire nested loop section to understand the developer's intentions from the outset.

For instance if I see map, I understand they must be producing a collection based on the input. If they're using reduce, they're figuring out some property of the entire collection.

Also (this is a big plus), the developer would have to go out of their way to modify the original collection, which is always a fun source of unexpected functionality when reading through traditional loops; map and reduce avoid this by design as modified collections are produced as output and don't surreptitiously modify the input. Basically by design you end up with fewer mega-loops that cram in updates, computation, and modify the source data in sneaky ways.

Without reading the contents of the mapping and reduction functions, the grammar of this is very clear to me: "newCollection = (collection.reduce({criteria})) ? collection.map({abc}) : collection.map({def})" - I can see that I'm checking the collection for some criteria, then mapping the collection based on one of two criteria. The grammar itself tells me exactly what's going on before I even have to read the contents of the mapping and reducer functions. Sure that can also be accomplished with a couple of loops, but then I'd have to read through the loops to understand exactly what the broader intention is.

Anyway as I said I consider myself a pragmatist rather than an evangelist for any particular methodology. I don't consider myself a FP programmer but I've found some of the concepts useful tools to have around. Like anyone on a wage, time is money and I use whatever gets the result the client wants in the best way from time, budget, and maintainability perspective. But I hope at least the concept seems a bit less pointless / like code golf with the above context?