For destructive deployments we had an explicit DBA schema so the relevant data could backed up and be rolled back.  The deployment/rollback usually involved some form of sp_rename for the larger tables.

You do need an agreed RTO (recovery time objective) and RPO (recovery point objective).  For example, an agreement that a rollback will lose all data captured since the deployment.  Alternatively for a zero data loss rollback the rollback will be accomplished in 2days, recovery will prioritize recent data in order to provide full functionality for operational concerns at the earliest possible point.

There should be space in the DB for such tables simply because you need space for reindexing.  As rollbacks are rare you can put the DBA schema on its own filegroup with its own file mount.  That gives you options with regards to cost of the solution.  Having a separate schema for data rollback also keeps the main schemas clean and allows a clear retention policy to be defined for the DBA schema.

One thing I think would be useful would be the ability to BCP out data into Parquet files.