As far as my "experience" goes,
repair_allow_data_loss never actually fixes the problem. What it actually does is it deletes as much as culprits(corrupt pages) possible to make sure whatever left is consistent. This should always be your last resort to get out of the data corruption. Moreover what it also does is removes those valuable constraints/business constraints on which your very logic is designed leaving database in vulnerable state.
A bit of advantage MS provides here is we can run the
repair_allow_data_loss in a transaction, but not actually commit it, and gauge amount of data loss and broken database you get. Then you can actually decide further course of action.
I am quoting a warning section from BOL Document about repair_allow_data_loss
The REPAIR_ALLOW_DATA_LOSS option is a supported feature of SQL
Server. However, it may not always be the best option for bringing a
database to a physically consistent state. If successful, the
REPAIR_ALLOW_DATA_LOSS option may result in some data loss. In fact,
it may result in more data lost than if a user were to restore the
database from the last known good backup. Microsoft always recommends
a user restore from the last known good backup as the primary method
to recover from errors reported by DBCC CHECKDB. The
REPAIR_ALLOW_DATA_LOSS option is not an alternative for restoring from
a known good backup. It is an emergency “last resort” option
recommended for use only if restoring from a backup is not possible.
Certain errors, that can only be repaired using the
REPAIR_ALLOW_DATA_LOSS option, may involve deallocating a row, page,
or series of pages to clear the errors. Any deallocated data is no
longer accessible or recoverable for the user, and the exact contents
of the deallocated data cannot be determined. Therefore, referential
integrity may not be accurate after any rows or pages are deallocated
because foreign key constraints are not checked or maintained as part
of this repair operation. The user must inspect the referential
integrity of their database (using DBCC CHECKCONSTRAINTS) after using
the REPAIR_ALLOW_DATA_LOSS option.
Before performing the repair, create physical copies of the files that
belong to this database. This includes the primary data file (.mdf),
any secondary data files (.ndf), all transaction log files (.ldf), and
other containers that form the database including full text catalogs,
file stream folders, memory optimized data, etc.
Before performing the repair, consider changing the state of the
database to EMERGENCY mode and trying to extract as much information
possible from the critical tables and save that data.