> イテレータは抽象化されてるので密結合はしていない
イテレーターパターン推し連中の公式見解だな。
ただ、目的とどこまでやるべきかを考えれば、問題点は簡単に分かる。
俺は、

目的： 同一コードを走行させる為、コンテナ非依存にする為
どこまで： 全部

と考えてる。抽象化が「本質(共通）部分のみを抜き出す」事なら、共通部分が残っているようなら抽象化が不十分だ。
iteratorを使う際には必ず「ループの中に入れて.next()を呼び出す操作」が必要で、つまりこの部分
for (=iter.begin(); !=iter.end(); =iter.next()) {}
が共通で残っており、毎回自前で同じようなコードを書け、となってる。--- (A)
ならこの部分もついでにイテレータに入れた方がよくね？と考えれば、
itereator.each(関数ポインタ）形式になり、まんまforEachになる。 --- (B)
だからイテレータとforEachは発想としては連続的につながっており、思いつけないものではない。
敢えてイテレータ(A)で止めてるのは、当時覇権言語だったJavaが関数ポインタを使えず、(B)を記述する能力がなかったからだ。
つまり、

OOP：イテレーターパターン： for (=iter.begin(); !=iter.end(); =iter.next()){ 中身の処理 } --- (A)
関数型：ダックタイピング： container.forEach(関数ポインタ) --- (B)

であって、どちらも目的を達成出来るが、for の呪文を毎回書かなくて済む分関数型の方がいい。
だからあの関数型アゲは腐りきったデザインパターンへのアンチテーゼの意味もあると思ってて、
実際デザインパターンアゲが消滅次第、関数型アゲも消滅したろ。