Not much to add other than the same pointer.

I strongly relate to this. Zen was a huge part of what sold me on InterSystems tech 15 years ago when I started here as an intern - for all the reasons you've described - and if I want to throw together a really quick POC that just has results of a class query shown in a table, with maybe some basic interactions with the data, I might still use it.
That said, for my team's work and even for my own personal projects, I've found the combination of isc.rest and isc.ipm.js to be *almost* as quick as Zen. With something like Angular with an IRIS back-end (consisting of a bunch of %Persistent classes), you need to write:
1. REST APIs for all your basic CRUD operations, queries, and business logic
2. Client code to call all those REST APIs
3. Client code for all the models used in those REST APIs
4. The actual UI
Suppose you want to make a simple change to one of your models - say, adding a property to a class and making it available in the UI. With Angular, this probably means changes at all four levels; with Zen, you get to skip 1-3 entirely. That's compelling. An inevitable side effect of this is that your application's API surface (and therefore attack surface) is enormous and near-impossible to fully enumerate. It is possible to secure a Zen UI, but much easier to shoot yourself in the foot.
isc.rest makes (1) super easy - add a parent class to your %Persistent class and do a few easy parameter/method overrides to get CRUD and queries basically for free, and write a bit of XML if you want to do fancier things to expose business logic or class queries. This provides enough metadata to generate an OpenAPI spec, which can then be used to automate (2) and (3) with the help of openapi-generator. So while you can't skip 1-3 entirely, this toolset makes it all significantly faster.

You might want to submit that here: https://community.intersystems.com/post/3rd-intersystems-ideas-contest

I like this in combination with a global mapped to %ALL that has:
^SYS("ConfigDatabaseOverride","BAR")="^^:ds:BARCONFIG"
So prior to references to the possibly-mapped global, you'd look to see if there's an override for the current namespace, and if there is, use it.

Examples:

Create a class DC.Demo.UpToDate and save/compile it.  $System.OBJ.IsUpToDate("DC.Demo.UpToDate") returns 1. Add a method with /// documentation and save but don't compile - it returns 0. Change the /// documentation for the method and save (don't compile) -  $System.OBJ.IsUpToDate("DC.Demo.UpToDate") returns 0, but $System.OBJ.IsUpToDate("DC.Demo.UpToDate",0,1) returns 1.
Create a routine named DC.Demo.UpToDate, save and compile. This returns 1:
##class(%Library.RoutineMgr).%OpenId("DC.Demo.UpToDate.MAC").UpToDate
Save and don't compile. This returns 0:
##class(%Library.RoutineMgr).%OpenId("DC.Demo.UpToDate.MAC").UpToDate

Scott, I'd recommend reaching out to InterSystems Support on this. My gut feeling looking at that message would be that your web gateway configuration is incorrect. Specifically, maybe the web gateway itself is trying to connect unauthenticated, which isn't allowed (because UnknownUser can't use %Service_WebGateway), and the request just happens to be for the /api/atelier web application.

@Herman Slagman how did you have the background process do that? (Just curious; this could be simpler.)

@Enrico Parisi thank you for bringing this up, we'll try to turn around a fix shortly.

No offense taken - if you're working on a local dev environment/container/etc. it's absolutely a better experience to use a third party GUI rather than Git WebUI from git-source-control to manage things; the purpose of the source control extension in that case is just to do export of things in IRIS to the local filesystem. I generally just use GitHub Desktop. The Git WebUI is significantly more valuable in a remote / shared development environment where the alternative would be SSH'ing in and running git commands. This is still a valid option if you prefer and for the rare edge cases where something gets stuck.
One clarification, though - the Git tools in IRIS Studio *do* carry over to VSCode if you're using isfs for server-side editing.