Как уже сказал @eviltrout, мы сейчас успешно используем миграции и выделенные таблицы в ряде плагинов. Возможность применять ограничения на уровне базы данных помогла повысить производительность (поиск по любому столбцу) и целостность данных (благодаря уникальным индексам). Эти два аспекта оказались особенно важны для масштабов некоторых наших хостинговых клиентов — о таком я раньше, до вступления в команду, даже не задумывался.
Первым значимым плагином, над которым я работал, был chat-integration. В нём я реализовал довольно сложный «фейковый ActiveRecord», опирающийся на хранилище плагинов. Сейчас, оглядываясь назад, понимаю, что выделенные таблицы были бы гораздо лучшим выбором, и, возможно, в будущем я рассмотрю возможность миграции этого плагина на такую архитектуру.
Я согласен, когда речь идёт об изменении основных таблиц. Добавление или изменение столбцов в существующих таблицах может иметь непредвиденные последствия в будущем, и эти изменения останутся даже после удаления плагина. Я настоятельно не рекомендую так делать.
Выделенные же таблицы сопряжены с относительно низким риском. Если плагин будет удалён, эти таблицы просто останутся в базе, не вызывая никаких негативных побочных эффектов (при условии, что вы не создадите ограничения внешних ключей). Оставление данных в базе «не хуже», чем использование хранилища плагинов.
Что касается очистки, мы могли бы рассмотреть возможность предоставления задач Rake, которые «отменяли» бы миграции плагинов для удаления данных. Но честно говоря, я не думаю, что это будет востребовано. Я исхожу из того, что люди редко удаляют плагины, а если и удаляют, то предпочитают оставить данные на случай повторной установки плагина.