* How does the author suggest non-blocking DDL is actioned? You'd have to snapshot your entire table using e.g. a similar method to snapshot isolation at the row level to allow concurrent access. Accessing the table, while in transition, will lead to inconsistent output data sets.
* If your migration is 'days-long', then you are doing something wrong. Try creating a new table (instant) then ETL'ing your data over from the original, dropping and renaming. It will be much faster AND it addresses accessibility on the table (no table lock).
* You can schedule migrations if using a tool like Flyway by doing this in code. If you insist on using a database product, you could use (for MSSQL) SQL Agent, or cron for anything on Linux (run a SP), etc.
* It is already possible to revert a migration if you are using Oracle, using Oracle Flashback. For other DBs, you can still revert a migration if you are using your deployment tool properly i.e. redeploy an earlier version of your schema and drop all other objects. You'll have to deal with your data, of course.
This would have been a more interesting post if a possible solution to all the points was posited.