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.

How do you go about turning on the modern view? I've installed a fresh instance of 2025.1 but do not see an option to switch to the new views in the Production Configuration screen.

Presuming that you're trying to script input into a menu-driven routine to generate data or perform some action, the best course of action would be to analyze the code of the legacy menu routine and see what it is calling to actually generate data or perform the action based on the menu input and have your endpoint call that code directly with the proper inputs from your REST endpoint, bypassing the need for the menu and any scripted input. 

I'm amazed at how little code is actually required to get a fully operational server application running! Nice work!