If something goes wrong during the upgrade part of the execute source code most times you have to restore a DB to start over. This is very time consuming and not necessary. If the drop table part from the upgrade step is moved to a new step drop tables, which would be placed at the end of the execute source code. This would mean that if something goes wrong during the upgrade step you could still check the data to see what went wrong. After solving the problem you could then just run the script again, since the backup tables still exist.
The only reason I can think of why the drop table is currently in this step is the removal of domains. This could easily be solved by using global temp tables.