DBマイグレーションの自動ロールバックの是非について

Question

質問したいこと

DBマイグレーションの自動ロールバックの是非についてご意見いただきたいです。

背景

CDパイプライン（GitHub Actions）で、DBマイグレーションを行っています。（golang-migrateを使用）

jobs:
  migrate:
    runs-on: ubuntu-22.04
    timeout-minutes: 30

...（省略）
      - name: migration up
        id: migration_up
        run: |
          migrate -database "postgres://$DB_URL:5432/center?user=$DB_USER&password=$DB_PASS&sslmode=disable" -path ./database/migration up

      - name: set dirty migrate version
        if: failure() && steps.migration_up.outcome == 'failure'
        id: dirty_migrate_version
        run: |
          version=$(migrate -database "postgres://$DB_URL:5432/center?user=$DB_USER&password=$DB_PASS&sslmode=disable" -path ./database/migration version |& awk '{print $1}')
          echo "number=${version}" >> $GITHUB_OUTPUT

      - name: migrate down
        if: failure() && steps.migration_up.outcome == 'failure' && steps.current_migrate_version.outputs.number != steps.dirty_migrate_version.outputs.number
        run: |
...（省略）

自分はこれまでマイグレーションのロールバックを自動化したプロジェクトに参画したことはなかったのですが、現在参画中のプロジェクトでは上記の通りマイグレーションに失敗すると、マイグレーションレベルで自動的にロールバックされるようになっています。先日マイグレーションが失敗しロールバックされた際、このワークフロー内で行われているロールバック先のバージョンの計算にバグがあり、DBが壊れるということがありました。
幸いにもデモ環境であったため、Amazon RDSのクラスターバックアップから復元できたのですが、稼働中のリリース作業のため、本番環境であれば復旧も大変なことになるな、と危惧しておりました。結局チーム内では「自動ロールバックされないとマイグレーションが途中魔で成功した状態で放置されることになる」ということで、デモ環境で発生したマイグレーションの失敗自体の解消と、GHA内のワークフローのバグを修正して無事本番リリースすることができました。
ただ、結局これが安全なやり方だったのか疑問が残ります。
PrismaもAuto Rollbackはサポートしておらず、代わりに「expand and contract pattern」を推奨しているようです。
https://mintlify.wiki/prisma/prisma-engines/schema-engine/migrations#why-no-down-migrations