One issue I haven’t seen mentioned: map and filter have both obvious semantics and obvious implementations in the sense that (aside from possible laziness) there is really only one thing they could do, a parallel implementation is essentially semantically identical to a non-parallel implementation, and there are no potential numerical issues (used broadly in the sense of functions that are, say, ideally associative but not actually associative in real life). You apply the function to the input and you either collect or filter the results.
Reduce could mean one of quite a few things. (How many folds does Haskell have? At least six.) And most of them are, in a sense, so trivial that there is no real benefit to spelling it “fold” or “reduce” instead of just calculating it explicitly. (Okay, one can sometimes lazily fold a lazy list, for example by applying the identity. This is not the normal case, especially in eager languages, which is most of them.) And, if you just write a loop instead of “reduce”, then it’s more obvious what’s going on and why the code might be inefficient.
IMO the actually interesting case of reduce is the associative case, which can be parallelized. This is not the default in most languages.
Reduce could mean one of quite a few things. (How many folds does Haskell have? At least six.) And most of them are, in a sense, so trivial that there is no real benefit to spelling it “fold” or “reduce” instead of just calculating it explicitly. (Okay, one can sometimes lazily fold a lazy list, for example by applying the identity. This is not the normal case, especially in eager languages, which is most of them.) And, if you just write a loop instead of “reduce”, then it’s more obvious what’s going on and why the code might be inefficient.
IMO the actually interesting case of reduce is the associative case, which can be parallelized. This is not the default in most languages.