Is it really much extra work to do the migration online instead of offline? It's just that second step where the application writes to both tables (and usually a step where reads switch to the new tables). Everything else is necessary for either method.
In many situations taking downtime for it is more expensive for development. When taking downtime, often you need to be really damn sure it works beforehand so you don't take unnecessary down time. Having to roll back and try again later after fixing something (and eating more downtime) can be a bit embarrassing. When you are doing migrations without downtime you can take your time between each step and add additional validations that might be impractical when trying to minimize downtime.
If you don't need to minimize downtime then maybe it doesn't really matter but that situation seems rare from my perspective.
> In many situations taking downtime for it is more expensive for development.
This is absolutely true, and the main reason for this is that the tooling sucks. Actually testing that your migration will result in your intended database state is difficult and thus people simply don't do it.
I've attempted to remedy this situation by writing a diff tool for Postgres, so you can confirm your migrations will result in a matching schema, and autogenerate more correct migration scripts.
In many situations taking downtime for it is more expensive for development. When taking downtime, often you need to be really damn sure it works beforehand so you don't take unnecessary down time. Having to roll back and try again later after fixing something (and eating more downtime) can be a bit embarrassing. When you are doing migrations without downtime you can take your time between each step and add additional validations that might be impractical when trying to minimize downtime.
If you don't need to minimize downtime then maybe it doesn't really matter but that situation seems rare from my perspective.