In my opinion, adding a trigger to the production database; creating a table in production database, dropping a table from production database, creating a job in production database - IS RELEASE.

Every change made in the production database should be considered as a release.

For example, adding a trigger could affect performances and should be planned ahead, tested, released, monitored. Same with the other changes which makes these steps actually:

Release I, Release II and Release III

Where does FKs fit in? (Their name has to be unique on the database level)

What happens in case of the replication, if changed table is published?

How this data transfer affects tlog and backup size?

What happens in case there is a log shipping set up on the database? How is space affected? How are performances affected?

Depending on the table structure and the way transfer is done, indexes can end up heavily fragmented if created before table is populated.

Although being useful in some cases, it seems to me that this approach has limited usage and hidden risks which should have been mentioned as well.