｢最適化｣ととらえている限り､遅延評価の本当の効果は実感できないと思います｡積極評価の発想のまま､その一部が良くなった､という見方だからです｡

遅延評価を前提にすると､ｺｰﾄﾞの書き方が発想の段階から違ってきます｡そちらの発想からすると､積極評価は｢逆最適化｣をやってるようなもので､それを回避するには遅延評価ですっきり書けるｺｰﾄﾞをわざわざ回りくどい方法で書いてやらないとならない､ように見えます｡

ただ､こういう発想の違いを短い例で示すのは難しいですね｡短い例だとどちらで書いてもそれほど複雑になりませんから｡一応､定番の文書として『なぜ関数ﾌﾟﾛｸﾞﾗﾐﾝｸﾞは重要か』http://www.sampou.org/haskell/article/whyfp.html がありますが､例に出ている問題の大規模版を書いた経験が無いとﾒﾘｯﾄがﾋﾟﾝと来ないかもしれません｡

質問者さんは､既にある程度まとまった大きさのHaskellｺｰﾄﾞを書いてみた後で､ﾒﾘｯﾄがわからないとおっしゃっているんでしょうか｡だとしたら､もともと合ってないのかもしれません｡それなら敢えて学習する必要もないのではないかと思います｡

実際にHaskellのｺｰﾄﾞを色々書く前の段階で迷っていらっしゃるなら､学習ｺｽﾄなんか気にならなくなるくらい興味を惹かれるようになるまで､置いておいたら良いんじゃないでしょうか｡ｼｪｱが少なそう､とか､時間を投資する見返りがあるかどうか不安､なんて思っているようじゃ､まだ本当に興味を惹かれてないってことですよ｡今使ってる言語で満足してるなら､それでいいじゃないですか｡