It's still a complex and more abstract function than map or filter. Those do a single thing that's easy to grasp. reduce/fold can be easily abused to duplicate the effect of most other collection functions, at the cost of making the code less readable. Although for slightly-too-clever people, that could mean you only need to know one function instead of all of them.

But it hurts readability. If you're going to do it, at least don't use it anonymously, but give it a name that clearly describes what's going on.

But even then, there can be hidden performance traps. I've often seen javascript that used reduce and created the new accumulator by using a spread on the old accumulator and adding the new one: `[...acc, newValue]`. But that spread is another iteration inside a loop, turning it from O(n) to O(n^2). A for loop where you append it is much faster.

Since you mention mnemonics, here are the mnemonics I use to remember the (symmetrical) differences between foldr and foldl

https://arialdomartini.github.io/fold-mnemonics

I admit that I have always looked at an explanation like yours with x1,...,xn when using fold because I could never keep it straight in my mind.

In other words, look at the types. The type of the folding function (the first argument) indicates how each fold works.

  foldl' :: Foldable t => (b -> a -> b) -> b -> t a -> b

  foldr  :: Foldable t => (a -> b -> b) -> b -> t a -> b