I am all for more FP constructs used in JavaScript. However, deeper roots of those need to be understood first, as well as evil of the mutable variables.

Readability is not that subjective. Simple for-each loops can be simpler than map-filter combos, but my argument was not about loops, but a clean functional programming construct called list comprehension.

What makes reduce less readable is (in my opinion) arity of 3 and arity of two of the function provided to it. One needs to remember whether iterable goes first or the reducer function (I am not talking javascript only here with it's method syntax), whether it's right folding or left folding. There is also a need to provide an identity element. And also remember the convention for the reducer (is current element or accumulator the first argument?). Too much to remember compared to the for-each loop.

By the way, we quickly go into beautiful mathematics of Category Theory, and it's catamorphisms.

In a sense, I see the point reduce can be quite readable and natural for those, who studied the math or established functional programming languages rooted in it.

I only wonder why Haskell programmers use https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/monad_comprehensions.html monad comprehensions and not stick with lower level functions to express the same?

So yes, reduce is good instrument, but it seems to me it's taken out of it's natural "habitat", and that is why it's clarity suffers. The map is way simpler, so I do not argue about it that much.