一太郎 Ver.3 時代とかに PC-98 用の Word があったとか聞いたこともありませんが。

一太郎が覇権を築き上げたのは Ver.3 までの時代で、Ver.4 で「なんだこのクソ重いのは」とちょっと敬遠されたりしたものの、Dash でなんとか盛り返したりしていた感じです。
この頃には日本語ワープロ的に Word と競合する世界はありませんでしたよ。

Word と全力でバンドル競合してた時期では、OLE で連携できて元々高性能な Excel とのセットに対し、一太郎 Ver.4 より重い一太郎 + 他社製でまともに連携できない Lotus 1-2-3 や、実績も何もない三四郎→三四六のセットだった筈です。あれ、三四郎とのセットあったっけ……?
まぁ、当時としては Word みたいに罫線が勝手にずれる一太郎に存在価値などなく、「ATOK 以外いらね」であって、ワープロアプリ自体が勝てる理由がありません。

東日本大震災の復興支援のために赤十字に寄付していたり、トップに「当社は、テラインターナショナル株式会社（代表取締役　宮本一成）です。 株式会社テラ・インターナショナルとは、一切関係ありません。」とか書かされたりしているかわいそうなテラインターナショナルになら、ちょっとくらい出してあげてもいいと思う。

「寄付を行う慈善事業家」とか、あまりにも美化しすぎです。
寄付を根拠に権利を要求するような人を "慈善事業家" と呼ぶなど、聞いたことがありません。

言葉は悪いかもしれませんが、「行動力がある馬鹿が最も質が悪い」を地で行っているようにしか見えません。
Apache Foundation から ban された直後には死ぬ死ぬ詐欺してた記憶もありますし。

Portableアプリが流行る理由を考えて見ませんか？
そうしたら、レジストリーの面倒くささとかがわかると思いますけどね。

親コメントにもある通り、ポータブルなアプリが利用するのは「移動が容易な設定ファイル」であって「ini ファイルであること」はどうでもいい訳です。
そんなに ini ファイルが素晴らしいのであれば、なぜ %AppData%/Mozilla 以下に .ini ファイルはほとんどなく、実際のプロファイル情報には .sqlite や .xml、.db などが並ぶのでしょうか。

また、移動プロファイルなどもある通り、レジストリーは固有のマシンのみに 100% 縛られるものではありません。
ini ファイルを利用したとしても、マシン固有の情報とならないように設定の保持や利用に開発側で気を使う必要がありますし、レジストリーであってもエクスポートしたり、環境移行ユーティリティー (OS 標準) でコピーすることも可能です。

ディスクスペースも現在は大量にあり、別に設定を特別なツールなしに読めるテキストでも問題ないし むしろそちらのほうが簡潔で自由度が高い。

Firefox の例などを出しましたが、「データ表現の能力が低い (一行のテキストのみ)」「速度面で不利」「アプリケーション側で情報を扱いにくい場合がある (階層的な表現はレジストリーと同等)」という面から、自由度が高いからテキストがいい→でも ini ファイルの表現能力じゃ使いにくいので、簡単なところだけ ini にして実際の情報は XML で、というパターンもある訳です。
速度面の影響は、テキストファイル一般では常に付きまといますね。

レジストリーを使わないとすると、iniしかありませんしね。

最近は .manifest とか .exe.config (いずれも XML)、そしてユーザー固有となるアプリケーションごとの情報は %AppData% 以下に (任意の取り扱いやすい形式で) 入れる、などという形が幅を利かせておりまして。

できるだけ、一旦壊れる起動できなくなるレジストリーみたいに全てを一緒くたにするよりも、iniのように独立性が高いほうがなにかといいと思いますけどね。

Win3.x 時代などの .ini ファイルに依存していた時代では、.ini ファイルが壊れたら普通に起動できなくなってましたけど。
今はレジストリーに依存しているから、レジストリーの破損が大きな影響がある、というだけですね。

また、アプリケーションのユーザー設定が格納されるのはシステム用のレジストリーファイルではなく、ユーザー固有のレジストリーファイルで、通常は %USERPROFILE%\ntuser.dat (バックアップも自動作成される) ではないでしょうか。
これが壊れてログオンできなくなることはありますが、Windows 自体が起動できなくなることはありません。

「何かと動きが鈍くなる」ではなく、レジストリーからの読み出しなど、アクセスが発生するタイミングでの遅延が発生する、ですね。
これは、不要なエントリーが存在していて、これを読み取るという無駄な作業が発生する事での遅延が起きる、ということです。
また、もう一つあるのがレジストリーを格納するファイルの肥大化の原因となったり、フラグメントの理由となる、という事です。こちらも低速化の原因となります。

これらを ini ファイル消し忘れのパターンと比較してみます。

「読み取りが発生するタイミングで、利用しない無駄なエントリー/内容を読み込む無駄の発生」は、これは普通に発生しますね。該当フォルダーの一覧取得やデスクトップ検索などが無駄に読み取るパターンです。

「肥大化の原因やフラグメントの理由となる」点についても、こちらも「普通のファイル」である以上、発生しえます。
NTFS の場合、小さなファイルは MFT 内に入りますから、削除し忘れの場合はデータ領域のフラグメントよりもより解消し辛い事となります。
MFT の肥大化は (ある程度大きなサイズをまとめて確保していく MFT の特性上) ディスクスペースの占有、IO 性能の低下などをもたらしますし、断片化はファイルアクセスに顕著な悪影響が発生します。

レジストリーであってもファイルであっても、ゴミは邪魔になるし、大量にゴミが発生するような使い方であればどっちにしろ悪影響は避けられません。

つまり、3DS ゼルダのように「本体を上に持ち上げ、下から見る」と……ということですね。

# 任天堂機でそんなの出るとは思え……魔女神判とかあるからわからないか。

大抵メモリーやディスクのフラグメント発生による「だんだん重くなっていく現象」は、いまどきの OS であればすべて発生します。

また、そういう現象に遭遇したことがない (または、発生しているのかもしれないけど無視できるレベルでしかない) のですが、自身の要求にハード性能が追い付いていなかったりしませんか。

「Metro アプリなら、アプリケーションやユーザーデータ、設定は残る」訳ですから、たまりにたまった RSS や IMAP のキャッシュなどや、ユーザーが勝手に突っ込んだデスクトップアプリケーションなどをごっそりと簡単に消せる、という感じではないでしょうか。

機能に対して、ツッコミの方向性が違うように思います。

HDD なら大したことない話ですが、SSD だと色々致命的だと思いますが……。

RAM 16GB な SSD 機の場合、ざっくりと Win7 x64 で 10GB、ページファイル + ハイバネーションファイルで 32GB と、これだけで 42GB 持って行かれます。
ここにアプリケーションを入れてデータもある程度……となると、64GB クラスの SSD では色々無理がありますし、120GB クラスの SSD でもギリギリではないでしょうか。