@evitrout が述べているように、現在、複数のプラグインでマイグレーションと専用テーブルを採用しており、大きな成功を収めています。データベース制約を強制できる機能により、パフォーマンス（任意の列でのルックアップ）とデータの整合性（ユニークインデックスによる）の向上が実現されました。これら 2 つの点は、一部のホスト顧客の規模において特に重要であることが証明されています。チームに参加する前は、このようなことをあまり考慮していませんでした。
私が最初に本格的に取り組んだプラグインは chat-integration で、プラグインストアに依存する非常に煩雑な「擬似 ActiveRecord」を実装しました。振り返ってみると、専用テーブルを採用していた方がはるかに良い選択だったでしょう。将来的には、このプラグインを専用テーブル方式に移行する可能性もあります。
コアテーブルを変更する場合については、同意します。既存テーブルへの列の追加や変更は、後々予期せぬ結果を招く可能性があり、プラグインをアンインストールしても残ってしまいます。これについては強く推奨しません。
一方、専用テーブルは比較的リスクが低いです。プラグインをアンインストールしても、それらは単に残るだけで、負の副作用はありません（外部キー制約を導入しない限り）。データを置き去りにすることは、「プラグインストアを使用する」ことよりも悪いわけではありません。
クリーンアップの観点では、プラグインマイグレーションを「逆転」させて整理する rake タスクの提供を検討することもできます。しかし、正直なところ、これはあまり利用されないと思います。私の仮説では、人々はプラグインをアンインストールすることは稀であり、仮にアンインストールする場合でも、再インストールする可能性に備えてデータを残しておきたいと考えているだろうということです。