I agree the single file argument is not extremely convincing. Especially because engineers are often on Mac on Windows machine and compiling for Linux. While Go does support this, as soon as you have to use a c library dependency (in my experience this was sqlite), then we had to start compiling in the environment we wanted. Easy to solve with docker but deployment wasn't the reason I like Go.
I should spend some time thinking about why but overall I just "feel" more productive with Go vs Java (including Kotlin). Go's standard library, docs (with links to the source code), everything just feels super readable and understandable.
I don't see much debate agains Go using less memory. I can confirm this was my experience as well. My experience is that it uses a lot less CPU as well.
No it isn't. On many times I've been able to simplify golang code that is dozens of line long into something that is only a few lines long in Java, while improving readability and reliability. This is especially useful when exploring a new code base and spending a lot of time perusing boilerplate trying to figure out what's going on.
Go was designed to be a language that development scales very well with it's focus on simplicity and very fast compile speed.
Rust on the other hand, was designed to make certain hard things less hard, at the cost of complexity, ease of learning, speed of development (high amount of restrictions) and compile speed. If you have a multi-million line monolith made in rust, I bet your compile speed and edit-build-run cycle will take a very long time and be very painful compared to the same golang one. Hiring will also be harder because the minimum IQ & experience bar is higher and you couldn't have productive jr engineers get up to speed on it nearly as quickly.