All of this is absolutely terrible advice, and can only make a bad situation worse:

And it will also throw out the transaction log, which should instead be backed up and used to recover from a backup from before corruption.

This database is online; there is no need to discard the log and force data distruction.

Please do not take any of that advice. At this point you can still recover the data and the database, but those steps will prevent you from doing so.

Just glancing over the checkdb dump, this looks like disk-based corruption. If your transaction log and transaction log backups survived the event, then you can backup the log (with the NO_TRUNCATE option if things are damaged), and attempt to restore the database from backup, rolling forward and through the corruption. The changes caused by disk-based corruption are not written to the SQL Server transaction log, allowing you to replay all of your transactions on a non-damaged restore (again, provided the transaction log survived the event).

If you cannot recover from backup, then you can at least take a new backup of the damaged database (yes, you can back up and restore corrupted databases), and perform all of your DBCC repair work there to see how much gets deleted if you use a repair_allow_data_loss. It is also possible to try upgrading the corrupted database to a newer version of SQL Server (this works, too) that will use a newer version of the DBCC CHECK* tools.