@anonymous - worth considering a migrations-based approach, so you can explicitly decide what changes are made to your database. Alternatively consider using a pre-deployment script that drops / truncates your tables.

When we work with ETL processes that will fill up data like in data warehouses, this would be very useful. Altering a column could take a lot of time on bigger tables, and the data will be usually re-inserted as part of the etl processes anyway.

We can always have extra option to drop and create tables instead of alter.
There are scenarios where we want to move new data to prod tables and flush out existing data and don't want to alter tables as we need columns in the order we have it in our development database and also for data transfer using partition switch in/out which requires similar table structure in both target and source.

I don't think it will harm any process unless user especially selects this option during deployment.

This seems like a bad idea to me. A primary goal of these tools is to preserve data.