It should be noted Go hasn't spit out static executables by default for at least 5 years now (if not longer), and if you want static executables from Go it requires several arcane incantations (not unlike getting a static binary from GCC).
Basically every Go executable is dynamically linked against libc these days unless the builder goes seriously out of their way to get a static binary.
$ go version
go version go1.18.3 linux/amd64
$ cat static.go
package main
import "fmt"
func main() {
fmt.Println("static")
}
$ go build static.go
$ file static
static: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=TSoFKMWZzy5G6qyFvxx5/dwEbvdQns9f-iffR-lbW/iTmqy3UF8tbT-GGwVH61/lUZUt7_XebTifpVvE_52, not stripped
$ ldd static
not a dynamic executable
But it might not be the case for all systems. And some things, like using CGO or performing DNS lookups, will necessitate dynamic linking.
As a Go user who values statically linked executables I can definitely say I was around when this was the only thing our compilers could spit out.
The reason I value it is because it makes deployment so much easier. I've re-lived DLL Hell so many times on so many systems by now that I'll happily take the memory/filesystem/pactching pain to have something I can deploy and know it will run on the system I deploy it to any day of the week.
Not just Go users. Nearly all products be it desktop GUI applications that self-update or backend servers I've ever developed are like this. Saves me a lot on deployments.