Sorry, I guess the rationale here is more that DB schema changes (at least for most "basic" web applications) go through the same codebase as normal application

Sorry, I guess the rationale here is more that DB schema changes (at least for most "basic" web applications) go through the same codebase as normal application changes, so it's in the same pipeline of changes as other changes. By asking for changes to be done in a highly-available way, you reduce coordination efforts needed for release. "Our main branch is always deployable" is a great default! And while actualy DB schema changes aren't multiple times a day, even on a relatively small team simple DB changes come into the pipeline once a week? Most aren't backwards-incompatible, but the beauty of it is that we don't even have to consider that much, because of this strategy. Maybe the "no downtime" stuff is unreasonable. In my case, we are a relatively small team servicing a good amount of customers (who do time-sensitive work), so the effort here is worth it. But if you can get away with it (with downtime windows being big enough to recover from issues), then it's definitely gonna be easier.