For me, a rollback occurs when the release is having a high financial impact on the company. All of the releases I do are for internal-only tools and systems and go through several stages of development and UAT prior to going live.
95% of the time, when a release goes sideways and a rollback is requested, it is because the release introduced a bug. When this happens, we investigate what caused the bug, evaluate the effort to correct the bug vs rolling back the release, and pick the appropriate action. Most of the time, fixing the bug is the desired action as rolling the code back means we are going to be rolling things back, fixing the bug, and re-releasing the application. Plus, since the bug was not found with internal or external testing, it is likely that the bug is not a "show stopping" bug, but more of an annoyance that they can live with for a few days.
The 5% of the time when the release goes sideways, the transaction will get rolled back and no harm is done.
If the release involves data changes or table structure changes, the first step we ALWAYS do is to make a copy of the data that will be changed. This gives us a snapshot of what the data looked like prior to our changes and allows us to revert the changes without doing a restore. Downside is it wastes some disk space as we now have a table that is VERY likely never going to be used again. On the plus side - all of these new tables have the current date in the table name so at a future time, we can drop all tables that are over a year old as it is VERY unlikely we are going to be rolling those back.