Right, but my point was that renames in particular typically can't go out well before the corresponding application change [1]. Thus, renames are "out of band" relative to the company's normal schema change process. (This is orthogonal to how schema changes are always "out of band" relative to code deploys; that wasn't what I was referring to.)

[1] In theory a custom ORM could have some kind of dynamic conditional logic for table or column renames, i.e. some way to configure it to retry a query with the "new" name if the query using the "old" name fails. But that has a huge perf impact, and I'm not aware of any common ORMs that do this. So generally if you want to rename a table or column that is already used in prod, there's no way to do it without causing user-facing errors or having system downtime during the period between the SQL rename DDL and the application code change redeploy.