First off, I'm not an ML-language guy: I have written a small amount of Haskell and respect the work those guys have done, but I'm more of a Scheme and Python guy. And I'm not super ideological about functional programming either; I write a good amount of C and some assembly.
I am all for making pragmatic compromises. Part of what offends me about Go is that they've coopted the idea of pragmatism as their own when in fact the design decisions made by the Go language aren't pragmatic for most users. Pragmatism is rooted in knowledge, having thoroughly investigated solutions and chosen the best based on your goals, not just giving up on implementing stuff because it's hard to implement (which I suspect is what the Go team actually means when they say something's not pragmatic).
In the end though, I think the reason I care is that Go's popularity poisons the industry as a whole. It eliminates places I'm willing to work at, and worse, it lowers the caliber of programmers I can work with. Programmers who use `go generate` aren't going to learn how to use code generation that integrates with a type system. Programmers who unconditionally claim generational garbage collection is too heavyweight aren't going to be able to write programs that allocate larger amounts of memory. Programmers who think "goroutines" are the newest, most innovative, one true way to do threading are going to shoehorn that model into their code in other languages, the same way I shoehorn threading models from other languages into my Java code, except I have a variety of models I've used and I can choose the right threading model for the right situation. And I'm going to have to work with these people at some point, and screen them out in interviews, and I'd rather we just didn't let this shitty language into our industry in the first place.
But let's take your argument seriously for a second and pretend that all these terrible designs are actually the best way to achieve Go's design goals: to make a language that compiles fast for giant codebases while maintaining reasonable performance for a huge infrastructure (Google's). If that's the case, why are you using Go? There are a very small handful of companies where these design goals even make sense as goals even if they did achieve them. If you're going to claim that this is about different design goals, then I'm just going to claim that those very design goals are why you shouldn't be using Go.