Unfortunately, in my experience once you are operating at scale they are expensive, slow and fraught with peril.

The result is that engineering teams often chose to build poorly designed schemas and take on technical debt rather than make a schema change to a core table. This is a terrible anti-pattern!

I'm massively in favour of anything that makes schema changes cheaper and more boring. I really enjoy working with the Django schema migration system for this reason - though it won't help you as much if you need to make schema changes to older versions of MySQL (I've not tried schema changes against 8.0 yet) since you'll likely still need to use GitHub ghost or Percona pt-online-schema-change.

Because it makes the migrations much more robust and way easier to develop & test.

If something goes wrong in a migration script, everything is rolled back. You edit the part that caused the error and simply run the whole script again.

And despite of thorough testing, there is always the possibility that it fails when applied in production. You want that migration to be completely successful or not at all.

Think e.g. splitting a table into two (which also includes DML) or moving columns around while creating new foreign keys.

You might not need to put the whole migration into a single transaction, but at least combine some steps into one - but this is only possible if the DDL statements are transactional.

Because I used to have to do that all the time seemingly before I finally got to pick my toolchain and I chose Postgres