That's the point---rather than create a tooling ecosystem that forces a particular IDE choice upon developers, Go is aiming for a set of minimally-sufficiently-powerful tools that IDEs can hook into.

Learning an IDE isn't a big deal, but it isn't, say, preferable to not having to learn one. I know Eclipse, but I avoid using it in all contexts where I can---it's slow, its project model borders on filesystem hostility (and still sometimes requires a "throw up your hands and delete a bunch of dotfiles" solution to fixing breakages in it), and even after years of refactoring and improvements it will still go "out to lunch" on garbage collection and force a pause in my process that most IDEs will not. Being forced to use Eclipse would be a hindrance for me in picking up Go (and I think a similar argument can be made for being forced to use (X|X element of IDEs) across all developers).

It isn't a big deal for you maybe. But I work in many different languages in a day. Switching IDE's/editors is a context switch I shouldn't have to make. Go is one small step in that direction.

You don't see an official recommendation because it's not necessary. Pretty much anything you use is going to have comparable functionality due to the work of the go team. Which is how I know that the Go team cares about tooling.

For the record I don't think you deserve to be downvoted like this. You stated a valid opinion. Go is not meeting a need you have and thus the value proposition for you is not the same as mine. This appears to be a case of people downvoting because they disagree not due to the quality of your comment.