I can't disagree enough. Time is too brittle of a system to rely on across various machines, especially since you can't be certain all machines can correctly report back the same UTC time. I've seen too many devs using VMs with way out of whack timestamps (VM's clock pauses when it's suspended, and they either forget, or didn't set up a hook to ntp). Also, when is the timestamp set? When the migration code is first written? That could lead to problems when the migration lives in a feature branch I started a month ago. Now that it's time to merge into master, I need to pull in upstream migrations and reorder my own migration to follow those. Using a timestamp here doesn't give any benefit over sequential ordering.

Second, if you have multiple migrations created on the same table by two devs that weren't aware of the others actions, this is exactly when a merge conflict should arise. This is probably less of a deal when both are schema migrations, but if both devs included a data migration, the result could be catastrophic if both migrations touch the same data. Human intervention is necessary at this point to make sure the order the system decided for the migrations is fine.

Third, if you've got a big team and either you botched your planning so much that you need a ton of migrations, or your policy freely allows everyone to create migrations without communicating with each other, you've got some major problems with your team.