That works for relatively simple scenarios. When you have to add deploying sql changes or something having to update something in the cloud, you'd have to include a lot more plumbing.
In my world CI/CD and db migrations are 2 different things working together. CI/CD at heart is rather simple for many setups. Migrations need quite a lot scrutiny, you really want to mess up there. But if you run on gihub actions with 50/50 uptime, does it matter?
Deploying SQL changes is actually trivial if you are using SQLite.
I agree in a hosted+shared SQL scenario you have to be a little bit more careful with all of this. Arguably, you should have a separate schema management phase in these cases.
But if you are just SQLite embedded in the service, you can use the user_version pragma to track schema version and perform deterministic migrations (assuming a user didn't manually jack with the file in-between).
We try to keep things simple. Everything has risks. No stall, run async, backward compatible. DB handles rollback via transactions. Happy to expand if interested.