Not picking sides here (though disclosure: I use and like FP techniques/tools/languages/libraries).

Go provides a set of nice features (fast startup, easy cross-platform building, great tooling, good package management) that can be hard to come by with other languages. It is not unreasonable to want to have your cake (all of the above features) and eat it too (occasionally use functional idioms in addition to the usual imperative ones).

For this reason I try to keep abreast of the various FP libraries in Go, though I have yet to use one in anger.

Because in some cases the aspect whether or not the language is functional is not the only decision criteria for the choice of language. If it was, I would absolutely recommend to consider a language than go. But if go is selected because of different criteria (i.e. interoperability with an existing eco-system, cross compilation support, FIPS compliance, ...) then this library can help to apply fp paradigms in you go code. Hopefully to make it readable and testable.