Making renaming work in the same kind of context is harder. You're definitely going to have to upgrade the application and the schema in lock step, unless the application is smart enough to work with the column having either name. You're also going to end up with some trouble if you ever reuse a column name, because then the next time you run the script it might rename the successor of the original column by that name rather than the column you intended to rename. So it seems more finnicky to use.
This I understand fully, and am fine with leaving it to the user to handle. They can choose whether rewriting the table (column add with non-null values) in order to have an easier application migration is better or worse than doing a rename and just ensuring that the old name is fully retired (which seems likely).
It can be used profitably and that is good enough for me given that we've already set a precedent of having IF EXISTS conditionals. That people need to understand exactly what the command will do, and test their scripts when using it, is a reasonable expectation. The possibility that some may not and might have issues shouldn't prevent us from providing a useful feature to others who will use it appropriately and with care.