My opinion - I would do whatever works best for the tool you are using. BUT I would also be careful about using a tool to monitor SQL error logs. The reason being you don't want a tool locking the log while it reads it thus preventing or slowing down SQL from writing to the log.
But if you are planning on writing the errors in a stored procedure to the log, that is not that difficult to do. RAISEERROR command will populate the log, just be sure you are selecting the correct severity and such.
Personally, I am not a big fan of "all in one" tools. I often find that when a tool claims to be able to do everything OR when I start hacking things together to have "one tool to rule them all", I end up with a tool that does everything poorly. What I mean is if I want to do database monitoring, I am going to be buying a database monitoring tool. If I am doing filesystem monitoring, I will buy a filesystem monitoring tool. OS? OS monitoring tool. There are benefits to consolidating monitoring and alerting into a single tool, but there are risks too. Recently, I had a SQL Server disk go from 80% full to 96% full and our OS monitoring tool gave no alerts about it. Thankfully our database monitoring tool could monitor disk as well and I got an alert. Later it was discovered that the OS monitoring tool had crashed and corrupted its own database, so it needed to be restored from backup.
What I am saying is that consilidation is nice as you have 1 location to view all the data, but redundancy is nice so when your main system fails, you can still get alerts that you care about. BUT if the tool can't handle the recommended method for capturing data, I don't want to create a hack to make it work. I would much rather have 2 tools that work well than 1 tool that I had to create some very specific steps to implement.
Now, on top of the above, where I work, our stored procedures are called by in-house developed applications. These applications are used for the error handling and logging. Our stored procedures have sanity checks and data validation checks and in the event an error may occur somewhere even after the sanity checks, we have try-catch blocks. On error, an integer error number is returned to the application along with an error string indicating what went wrong and that gets handled in the application side. Invalid input, for example, doesn't need to be logged. Failed insert, should be logged. But we handle the logging on the application side.
Now, for stored procedures called from jobs, if a job fails for any reason, it is investigated. A SQL job failure results in an email going out to the DBA team and someone on that team will investigate it. Once the problem is determined in the job, we work to correct the issue and to implement steps, processes, or changes to the stored procedure to prevent that error from re-occurring. We don't really have a need for a 3rd party tool to track those errors too.
Now, your situation may be different and you may benefit from those logs. If that is the case, I would still recommend following best practice and logging to a table. Once logged to the table, you can set up a job that selects from that table on a daily, weekly, hourly, yearly, whatever frequency makes sense to you and fire off an email to whoever is responsible for that system.
Now, if you REALLY want to use the AMP tool to review the failed stored procedures, I would follow best practice and dump the errors to a table. Then I would use something like SSIS or xp_cmdshell or SSRS or powershell to pull the data from that table and dump it to a file for the AMP tool to grab. You won't get real-time data that way, but you have the failure history in an easy to search format and you won't run into potential issues with log rotation causing things to be missed or lost by your AMP tool AND you don't run the risk of locking the SQL log file by accident. And in the event your dump file for AMP is locked, your job that was doing the dump will log that it failed and you can just re-dump the data.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.