$ZTRAP vs Try/Throw/Catch

It's not a dumb idea, but I would balance the risk you're introducing against the value. Refactor if you're already in the code, but if it ain't broke ...

The main thing to look out for is that the control flow is different. One pitfall of try-catch is that a try block is a context for quit, so if you have a quit command in a loop, then introduce a try-catch block, the quit may no longer do what you expect:

for i=1:1:10 {
    if i>4 {
        quit
    }
}

for i=1:1:10 {
    try {
        if i>4 {
            quit  // oops
        }
    } catch {}
}

Otherwise, I find try-catch easier to visualize than $ztrap. Unfortunately, there is no finally block.

Looking through some of my old code, I see a lot of $ztrap for restoring the previous namespace on error. A lot of those can now be replaced with new $namespace.

1: Yes 😉
2: See other comment on Quit
3: yes 😉
You should never 'modernize' for the sake of modernizing (refactoring is something else)
ZTrap is not old-fashioned, it's a mechanism other programming languages just don't have.
It is out-of-the-way, is doesn't introduce another stack level and it doesn't need extra indentation, it's just some code that you hope will never be executed, it isn't part of the main logic.
Try-Catch can be very useful for indeed a 'Try' for something you can't be sure how it will behave, such as
{}.%FromJSON(SomeJSON)

$ZTRAP is pretty much the same idea as ONERROR that you find in
BASIC, VB, VBA, JavaScript  and some other old languages.  
a left over from M
 

I am a huge fan of try/catch. The try is virtually cost-free with overhead only encountered when an exception is caught. I do agree with Jon Willeke - when I am in older code I normally do not refactor $ZTRAP unless the changes I have to make are more than a simple edit. I also use RETURN when exiting a function/method instead of QUIT.

It is possible to simluate a finally but it isn't as nice as having a real finally block would be.

I'm a big fan of try/catch, but I'm an even bigger fan of "if it ain't broke, don't fix it." This is one of those things that will sound simple, but you'll end up finding out that there are multiple different ztraps at different stack levels and an occasional etrap here and there, and then you end up rewriting way more code than you thought.