多くの言語で、ライブラリを管理するエコシステムが整ってきていることもあって、気軽に追加することも多いかと思います。ただ、ときどきは「削除」ということを考えたほうがいいかもしれません。
削除するシチュエーション
全く不要なライブラリ
ふつう、全く不要なライブラリを入れてしまうことはそう多くないかもしれません。ただ、状況によっては発生してしまうことがあります。
- プログラムの改造を繰り返すうちに、そのライブラリを使っていた機能がなくなってしまったケース
- 最初のインストール時に「標準的なライブラリリスト」を生成するけど、リストの中で自分の環境では不要なものがあった場合
使いもしないライブラリを入れておいても、完全にデメリットしかありません。不要だとわかったものは、きちんと消しておきましょう。
バージョン互換性の問題
npmで管理されるJavaScriptライブラリは、通常「グローバル展開」を行わず、必要な分だけローカルで読み出すような形となっていますので、「AのライブラリがCの3系列に、BはCの4系列に依存する」というような状況でも、両方のCを入れることで解決することができます。
とはいえ、こんな芸当が成り立つ環境は少数派で、RubyのGemでは同じGemの複数バージョンを共存させることはできません。なので、古いGemに依存し続けるGemは、どうにかして外さざるを得なくなることがあります。また、Rails本体が順調にアップデートを続ける環境下で、Rails用なのにアップデートが追いつかないGemは、遅かれ早かれ外すほかなくなってしまう場面が訪れる危険も大きいです。
処理系などのアップデート
処理系やRailsなどの基幹ライブラリがアップデートすることで、直接動かなくなるだけでなく、環境の変化でGemが不要となる例もあります（そして、そういう状況になったライブラリは、保守がなされず放置される例も多いです）。
たとえば、以前にちょろっと紹介した、特定文字のエスケープをC拡張に置き換えて高速化するescape_utilsというのがあったのですが、@joker1007 さんの提案で、Ruby本体にCで書かれたエスケープがマージされた結果、そっちのほうが速くなっている状況なので、もはや不要になった感もあります。
あと、Rails本体にActiveRecord::Enum、Webpacker、ActiveStrorageのような拡張が行われていっている結果、これらと同じ分野のサードパーティgemはお株を奪われているような状況です。