The costs and benefits of a particular programming style must be evaluated in the context of the language under examination. You can't take the benefits of functional programming in Haskell and blindly copy them into the benefits column of your Go analysis. You must actually do the analysis in the target language.

And once you do that, you will discover the cost/benefits of doing what most people call "functional programming" in Go is not very appealing. The costs magnify substantially and the benefits diminish greatly.

So... why would one do it?

(I qualify "what most people call functional programming" because my considered opinion is that "map/reduce/filter" isn't the interesting aspect of functional programming, but I'm still working on my guide on how to correctly bring the real lessons of functional programming back into imperative languages like Go, and this comment box is not enough to drop it all here.)