I agree around the desired outcomes regarding readability and side effects, but it's not like other languages can't be used in this manner. If you're an OO-ist and you design good interfaces with good contracts, the 'million ways involving half a dozen loops' can be very quickly limited in scope to a couple of methods in a small class.
That's not to say that it always happens, and certainly some less, uh, experienced developers will write terrible code. But they'll write terrible code in Haskell as well (or no working code at all, which has been my experience at least once).
I'd consider myself very comfortable with maps, folds, filters and zips. I wouldn't consider myself super fluent with their use in Haskell, which definitely contributes to my own struggles with the language.
But for something like the canonical quicksort example in Haskell, it takes me quite a while to figure out whether it's actually implementing quicksort by the book, or whether it's implementing something that sounds like quicksort but isn't. This is because I have to map the declaration to the underlying implementation when it matters. Probably more often than not it doesn't matter at all as long as the code works and isn't causing problems (which is where the functional primitives are fantastic), but I do find that digging deeper into a more complex functional algorithm can be a difficult task.
This is because you have to think about how every part might work behind the scenes. Am I doing something stupid like mapping my whole data set with a computationally intensive function? Is one of the innocent-looking predicates in my list comprehension actually some super intensive function that's had an operator overload? Am I going to be applying this predicate to the entirety of a massive list where in an imperative context I would have a really obvious switch case or set of ifs, a clear non-symbol invocation of reallyExpensiveFunction, and exited my loop early?
It's a little difficult to describe I guess, but for me reading [what I believe to be] idiomatic Haskell code at a high level is reasonably straightforward, if somewhat slow due to the compactness, but actually understanding what that code is doing can be incredibly difficult.
In some ways it's the same type of issue I have against liberal use of recursion. It might be reasonably easy to describe a recursive algorithm, but to really get in and understand it requires a much deeper understanding that's often easily more difficult than understanding its imperative cousin. There are real reasons why comp sci students struggle with it.