I used this all the time, mostly because of Red Gate bugs, but not necessarily. We may not know we need a migration script until a change is checked in and deployed to the next environment (using SQL Compare). After the deployment, then I would see the need for a migration script (often because of a RG bug that wouldn't make a change correctly). Then I had to go back and create a migration script that SQL Compare could use for the deployment to the next environment.
Please bring this feature back.

Here is the official workaround

https://documentation.red-gate.com/display/SOC5/Historical+migration+scripts

But this is insanely complicated compared to SC 4!

We also used migration scripts in SQL Source Control without the need to use SQL Compare. Is this just a way to force us to purchase SQL Compare? With the new method, I'm still not sure how to create a simple migration script based on a changeset. In practice, we create migrations that are promoted from DEV to QA to STG to PRD. Environments other than DEV don't need to be in Source Control.

Our use case is that our prod environment is only accessible via VPN. The SQL Compare option is painfully slow, like 30+ minutes to create a migration script. We've used a local empty DB that's linked to our prod source control branch and the select changesets feature to create the migration script. It has the added bonus of allowing us to manually double check the changes and even run them in pieces if we need to.

The use case for migrations mentioned here isn't something we ever intended SQL Source Control to be able to do. Our intention is that all deployment functionality exists in SQL Compare. However as a side effect of the old migrations feature was that SQL Source Control could do this. You're right in that the new migrations feature doesn't let you do this.

If you can drop me a note on jonathan.hickford [at] red-gate.com I'd love to find out a bit more and see if we can help.

Why was this feature removed????? so I had a product, it worked well, I upgrade the version and get less features.... now I have to buy a new product, is this right???

How we use migration scripts in V4: We have a shared database that we develop on. When new features are implemented the changes are checked in. We might make a number of changes relating to a number of different features. When it comes to testing these changes we use a migration script to update a test copy of the production environment. This migration script is generated by picking the committed changes we want to include. Assuming the changes pass testing then the same script is used to update the production database. Out test and production databases aren't linked to source control but I guess they could be.