The migrations table is used by typeorm to track which migrations have already run, so that it skips them and only runs the newer migrations.
If a record is deleted from that table, the next time typeorm migration:run is executed, the migration associated with that deleted record will run again, if it still exists in the code base.
I will update the answer with a source once I'm able to find it again, but I've also used this several times while testing migrations locally before committing my code (running typeorm migration:run, deleting the record in migrations, running typeorm migration:run and seeing the deleted migration run again).
Bonus content:
There was a scenario where we had an expensive migration that ran fine locally, got committed, and ran succesfully on a sandbox environment, only to cause a deadlock and fail when attempted in production (much larger table sizes).
We decided we'd revert the commit that introduced the migration, rewrite it, and attempt again.
For certain reasons I won't get into, we had to manually execute SQL to undo the migration in sandbox, but we decided to let the record in the migrations table be (another migration with the same name will still have a different timestamp appended and hence unique name) because we figured there was no harm in leaving it there, and it would also prevent this migration from ever running again in case someone messed up the git history and inadvertently introduced that migration again in the codebase. I do believe, however, that typeorm migration:revert does delete the record associated with the last run migration when reverting it.