The intentions of migrations is to go forward. You only go back while in development, if something is wrong, but imho only immediately after doing the migration and when a migration is not done on some other computer.
So for instance I create a migration, migrate, see I made a typo, rollback, fix the migration and migrate again.
Now if in the meantime, my super-fast co-worker has already migrated his database with the old migration, he will never know I fixed the migration, so he will still have the typo (since redoing migrations does not change any schema-versions). So if that is the case, instead of fixing/editing old migrations, I prefer adding a new migration that will fix the old migration explicitly, instead of rolling back.
In team-environments, but also when having multiple deployment-platforms, this is the preferred way imho.