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).
>Learning an IDE isn't a big deal, but it isn't, say, preferable to not having to learn one.
Everything else being equal, perhaps you are right. However by blessing one as the official editor the tools can be written to work with that rather than the lowest common denominator. This will make it more difficult for alternatives which is a cost, but I do believe the upside is worth it - unfortunately I can't prove it.
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).