Well, the usual "reasoning" is that Go is easier to maintain, faster, will require less hardware, etc... all of those things might be true. What is not told in is the other side of the story, the one where you will have to write, test, document and maintain a TON more code... which usually ends up in just overall lower quality as it is pretty hard to find developers writing better code than the code you usually find in popular full stack frameworks.

But managers/directors, etc aren't idiots. They swallow it and they accept it even if they know the trade offs, because what's not told here is that if management says "No, that's madness" then people quit, and that's worse. So there we go with our super performant microservices for our 10 reqs/s app.

Go autodocuments really well

Go has better safeguards to prevent bad dev behavior

There shouldn't be any more tests, you're testing an API either way

We're not talking here about documenting apis.

We're talking about documenting an architecture, how pieces work together, what tools are available, where to put things, etc. Check the documentation of any major web framework. That's what we're talking about.

What do you mean there shouldn't be any more tests?

huh? Go has had ORMs for ages and they are fine