If a BACKUP command fails it generates two error. The first the ERROR_NUMBER() you want. The second a generic failure ERROR_NUMBER() i.e. 3013 for BACKUP LOG.
This means that using TRY CATCH and initiating a proper response to a BACKUP LOG failure is very difficult.
Scenario A is using a BACKUP LOG <dbname> TO DISK = <Path> MIRROR TO DISK = <Path>.
I want to trap the error 3215. This is so I can switch to a WITH FORMAT.
Scenario B is that I am sending an output of errors to a log table. The error being sent to the log table tells me what I already know, the BACKUP has failed. So I need to run the task again to understand what the reason of the failure is. In the event of the failure being transient or a one off failure means that I would either not have the error or I'd need to use log files on the SQL job and not use TRY CATCH.