Типа можно накатить изменения и также безопасно откатить.
По поводу безопасного отката. Это на 99% зависит от SQL кода который вы напишете. Это никак не связано с фреймворком поддержки миграций. Берите какой угодно фреймворк. Например liquibase или flyway.
И даже в них если во время alter table rename column вы столкнетесь с активными сессиями в БД - то ваша транзакция переименования упадет и вы будете вручную решать ситуацию отката или наката.
Безопасность наката и отката также зависит от грамотности описания ваших чендж-сетов. Бывает так что в 1 чендж-сет запихивают 2 DDL команды и одна из них проходит а вторая не проходит и фреймворк повисает навсегда в клинче. Двигаться назад он не может т.к. Не был применен чендж-сет. И двигаться вперет тоже не может т.к. первая DDL команда уже выполнена и повторо ее вызывает ошибку типа "table/index already exists".
Выводы - грамотность описания чендж-сетов. И все.
Ваш фреймворк phinx выглядит ужасно с точки зрения кода. Как по мне он не делает главной задачи а именно - не является DSL для upgrade/rollback. Он - прибит гвоздями к PHP и следовательно его можно рассматривать только под углом вашего PHP-удобства. Удобен он вам? Используйте.
