mapで書くメリット
まずは、簡潔に書けていることです。
また、mapは「配列を加工して、別の配列を作り出す」という目的が明確に定まっています。
そのため、mapが出てきた時点で「ここの処理は別の配列に加工しているんだな」と判断することができます。
forのように幅広い用途がなく目的が明確なため、違和感(不具合)に気づきやすくなり、バグを生む確率がグンと減ります。
mapのアンチパターン
使用目的が定まっているため、map内で何かを実行したり、map外の何かを操作したり、加工以外の別の処理を行う事は完全なアンチパターンです。
filterで書くメリット
これもMapと同様に簡潔に書ける事、別の配列を作り出すこと、目的が明確なことです。
filterのアンチパターン
使用目的が定まっているため、mapと同様にfilter内で何かを実行したり、filter外の何かを操作したり、評価以外の別の処理を行う事は完全なアンチパターンです。
reduceで書くメリット
もちろん、簡潔に書けていることは言うまでもないと思います。
また、forで書く場合は必ずletでsumを定義しなければ、合計を計算できません。
letは極力なくした方が良いという考え方から、reduceで書く方が良いと思います。
(letは再代入可能なため、書き換えられる可能性が残る。)
mapでは実現できない配列の関係性から新しい配列を作り出せます。
つまり、reduceが出てきた時点で「ここの処理はmapでは実現できないような合計値を算出したり、グループ化を行っているな」と判断することができます。
reduceのアンチパターン
mapやfilterと同様に加工以外の処理はアンチパターンです。
またmapで実現できることをreduceで書くこともまたアンチパターンです。
(メリットにあるように、reduceが出た時点でmapで実現できない何かという考え方になるため)