It's definitely situational for me. I generally try to avoid using Quit for situations where I am trying to exit the method or program entirely, and opt for Return in these cases (a habit which took a lot of retraining since I'd been used to using quit for everything coming from a heavy MUMPS-coded software base in the past). I really only use Quit these days for terminating a loop when needed, but it's still a common enough usage for me. 
In short, these days I use these rules:

• Return - Exit program/method (with or without return value)
• Quit - Loop terminator

Throwing custom errors is a really handy tool to have!
You can also take this a step further and if you have code that returns a status (either built in functions such as %Save() or custom errors like you have here), you can deconstruct the status object to get into a nice output string using $System.Status.DecomposeError(). This is especially useful because functions like %Save() don't actually throw the errors again to the caller, they just return the status code from the error thrown within %Save(), so a try/catch won't catch these.

Take, for instance, the following test class. Notice the property on the class is of type %Integer, but in the class method I attempt to set the value to a string. This will cause an error when using %Save():

Class ErrorTest extends%Persistent {
    Property TestProp As%Integer;ClassMethod ErrorTest()
    {
      set objectReference = ..%New()
      set objectReference.TestProp = "Test"set status = objectReference.%Save()
      if status '= 1 {
        do$System.Status.DecomposeStatus(status,.errorlist)
        for errornum = 1:1:errorlist {
          write !,"Error entry ",errornum,":"write !,errorlist(errornum)
        }
      }
    }
}

If I were to wrap the %Save() call in a try/catch, it wouldn't catch the error thrown by the invalid property type when %Save is called. Using the method above, when I run the code I get this:

USER> do##class(Custom.Robbie.ErrDecomposeTest).ErrorTest()

Error entry 1:
ERROR #7207: Datatype value 'Test' is not a valid number
> ERROR #5802: Datatype validation failed on property 'Custom.Robbie.ErrDecomposeTest:TestProp', with value equal to "Test"

So, when you're using any kind of status, whether it be errors statuses returned by built in functions or custom made error statuses, you can use this to decompose them and get at the various pieces within if the error status isn't actually thrown to be caught by a try/catch.