I've used enough of these migration systems now that I'm convinced any system using sequence numbers likely has other, less noticeable problems since the problem space is complex and this is a known best practice of which the developers somehow remained ignorant.
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.
The idea is just to avoid a filename conflict which, even though the fix may be easy enough, can cause confusion for both the humans (developers) and for the schema management system itself (they usually just keep track of which versions have / have not been run).
Even just incrementing new migrations by random(0,1000) would, at least in theory, resolve the issue for the most part.
It just seems a lot easier to go ahead & use timestamps though....
So, forget about timestamp and sequence number. GUID is the way to go:
http://alembic.readthedocs.org/en/latest/tutorial.html#worki...
Otherwise I can also recommend liquibase, especially since they've since added support for non-SQL (JVM code) updates and rollbacks as well.