Just like index maintenance and a couple of other things, it's better to NOT do something than it is to do it wrong and, thanks to the poor examples in official documentation, a lot of people simply do it wrong.
I'm also dead set against using Try/Catch just to say it's in the stored procedure (for example). If the normal built-in error handling will suffice, why is there a need to rebuild that wheel in code?
I HAVE used Try/Catch to great benefit in some things (like sending an email and then "Continuing" backup loops if one backup happens to fail). I also do a fair bit of logging in my procs, if needed.
And that's the key... "If Needed" and "It Depends".
What's really troublesome for me personally is all the folks that write articles on how to use Try/Catch and get it as wrong as the MS documentation did but even the good articles on the subject miss something that is just as or maybe more important and certainly can be used to seriously augment the presence of good Try/Catch code. That something is how to properly use SET XACT_ABORT ON.
Even Brent didn't mention it in his article. Yep... I know his intent was to write about Try/Catch but my personal feeling is that no Try/Catch article and, certainly, no article that talks about error handling is complete without the why, when, and how to use SET XACT_ABORT ON.
Spoiler: Since I've never seen it cause any harm, my recommendation is of when to use it is "always unless you know a specific reason not to for the given stored procedure".