Author here, thanks for reading. As has been mentioned in some comments, the article only covers half the story of how this can be used for migrations. The greater idea is to have every commit be short-lived and two-phased: apply and cleanup. A migration is first applied and once it's no longer used by any clients, it's cleaned up.
1. Apply: the new schema is created and any new data is added to the backing table.
2. Cleanup: the schema is deleted and any data that is no longer needed is removed from the backing table.
For example, to perform a column deletion:
1. Apply: create new schema without the column which is being deleted. Don't change anything in the backing table.
2. Cleanup: delete the schema and the column from the backing table.
I've always liked the idea of using views as an API. But, I'd never considered using Postgres' schemas as a way of versioning that API. This approach wouldn't work for every kind of migration but definitely seems correct and useful in some cases.
As others have pointed out you still of course have to deal with the technical debt of clients using the "old" schemas/views... but that is a problem that has to be addressed anyway... so I don't consider that to be a "flaw" of this approach; it's something close to orthogonal to this approach.
1. Apply: the new schema is created and any new data is added to the backing table.
2. Cleanup: the schema is deleted and any data that is no longer needed is removed from the backing table.
For example, to perform a column deletion:
1. Apply: create new schema without the column which is being deleted. Don't change anything in the backing table.
2. Cleanup: delete the schema and the column from the backing table.