>>57
>破壊的な操作を内部に一カ所でも含む関数は破壊的になる

これは事実であり、特に純粋関数型言語であるHaskellプログラミングでは絶対的な真理でしょう
ただし、別の切り口による２つの考え方もありえると思います

最初の切り口は「純粋関数型 vs. 不純関数型」です
たとえば関数型言語のML族(F#/OCaml/SML)では、不変(immutable)データを操作する
透過的なプログラミングが基本の作法ですが、「例外」として明示的な参照型宣言や
逐次演算子(SMLの場合は ;(セミコロン))を用いた手続き型プログラミングも可能です
言い換えると、純粋関数型言語パラダイムではあらゆる破壊的操作を拒絶するのに対し、
不純関数型言語パラダイムでは例外を受け入れる寛容な思想です

そして、たとえ不純関数型言語パラダイムであっても、(手続き型言語パラダイムと比較すれば)
コード品質に関する明らかな恩恵を享受できることも事実です
Rubyによる関数型プログラミングもまた「不純関数型パラダイム」になります

もう一つの切り口は「ソフトウェアアーキテクチャレベルでの分離」です
たとえばRailsフレームワークは「MVCアーキテクチャ」をもとに設計されていますが、
ModelはRDB操作が、Controlerはセッション管理があるので破壊的操作は避けられないでしょう
でもViewに関してはRDBから取り出した値からHTMLオブジェクトへの「写像」という
純粋な関数として定義できると確信しています
つまり、(クラス/モジュールよりも粒度の高い)コンポーネント/サブシステムという単位で
破壊的操作コードと非破壊コードを分離することが、現場の開発では可能であると考えています

またMVCアーキテクチャはシステムを水平方向に分割しますが、
垂直方向にシステムを分割する「階層化アーキテクチャ」という発想もあります
つまり、I/O処理を含む下位層のコンポーネントは破壊的操作で設計し、
上位層を非破壊操作で設計することになります
もちろん水平分割と垂直分割を組み合わせることも可能でしょう
こういった(コード設計よりも上流の)アーキテクチャ設計も高品質ソフトウェア開発では重要です