Most of them don't do what they promise. I personally wouldn't use any.

As for what you use when repair doesn't work - restore. Restore from backup. Emergency mode repair is a last resort, it's not guaranteed to work, it should never be the first thing tried.

Fixing incorrect metadata is no where near as easy as you suggest. Irrepairable metadata damage occurs when there's no way to recreate the correct values consistently, so what should such a tool so? Make up values?

It's possible to repair a DB with a hex editor in some cases, such as damaged file or database header, I only know a handful of people in the world capable of doing it though and it's extremely time consuming.

In the case of a single row damaged in sysrscols, you would be able to query most of the database, only the table or index that is described by the damaged row would fail, so it would be possible, if tedious, to export all the other tables, possibly export some columns of the damaged table depending on indexes and then recreate the database. I've advised that several times in the past for databases with damaged system tables and no backups.

Every time I've seen errors around the size of the file, it's been that the metadata is correct and the file has been truncated on disk. That's not exactly fixable, it means a good part of the database is missing. Again, may be possible to construct SELECT statements to extract some data. That's definitely a 'restore from backup' case though.

To be honest though, a well-tested recovery strategy will server you far better than any 3rd party repair tool.