Every time I read something like that, I get the feeling that "Monolith to Microservices" is the pattern and the language doesn't matter.
At the beginning, a Monolith has huge advantages: easy to deploy, all in one place, smaller operational overhead, easier to manage with unclear requirements.
Later, it's easier to find out what you can split out and you can learn how to route and manage things piece by piece.
You exactly captured my sentiment, when I started doing this I don't realized all benefits. Because of Go's simplicity in deploying and maintaining, many small apps doesn't add much overhead. Now you can scale individual component.
Only risk is, you break things into many component then you should so balance is required.
As I said below, if you tread off the full-stack-track, you get a lot of the go-like things in Ruby as well.
My point being: I usually rate architectural changes as more important as a change in development details (and the programming language might be a big one there, but it still is one, IMHO).
I'll tell you why: a lot of the sentiments people bring when they now switch from Ruby to Go, I've heard before. When people started Ruby - I was already doing Ruby for ~2 years before Rails even came out at it got me into the position of saying: "just you wait until you see the bad parts". They attributed a lot of things to Ruby, while they were really changing their development model.
At the beginning, a Monolith has huge advantages: easy to deploy, all in one place, smaller operational overhead, easier to manage with unclear requirements.
Later, it's easier to find out what you can split out and you can learn how to route and manage things piece by piece.