「合流」を度外視する事
オブジェクトとは「合流」に備えた物だと思います。
それに対して、関数型は「合流」を（有るのに）見なかった事にする事で、（見かけ上）簡単に見えるので、（実効的に）簡単であるとする物だと思います。
関数による抽象
責務を担う関数は複数の手続きの集まりを囲ったものだと思います。囲いでおおい、一体化して見る事で、「合流」を見なかった事に出来ます。
しかし、その「合流」の『難儀のもと』は依然残ります。実効的にはより簡単とはなりません。
制御の反転
制御の反転（Wikipedia 日本語版）で、
- 制御の反転は依存性の注入と密接に関連している。依存性の注入は制御の反転を実現する有効な手法の一つである。
と有りますが、
依存性の注入をしても、昔からの依存性（「合流」によって生まれる『難儀のもと』）は、無くなりません。
「合流」自体を考えない事による”単純化”
関数型のパイプラインは、
- 複数の関数で、「合流」とは言えない様な、1つの原因からなる処理を
- わざわざ分けて
- それをパイプラインとしてつないでいる事で、
「合流」を見なかった事にして、簡単になったと言いますが、
- 見なかった事にして、
- 考えない様にしても、
- 「合流」（『難儀のもと』）は無くなりません。
結論
束因果ダイアグラムの様な議論が不明瞭な事が（「合流」について定式化しない事が）、関数型の、
- 見なかった事で → （実効的にも）簡単になる
という欺瞞を許す結論になるのです。
実効的に簡単になっている例は全く無いと思います。全て見かけ上です。
文字通り、
これからも「ソフトウェア開発での束因果ダイアグラムが不明瞭」な事で
「合流」の問題は現実に有るのに、無い様に言いくるめられ、プログラミングが嫌いになる人は存在し続けるのです。
この問題は本質的です。
