If you take a look at the example's source at:
You will notice, that they import
Which implements an http server - that's all, see here for more details:
It is not necessary, nevertheless possible, to use something like nginx or apache in front of a Go web application.
I'll concede that my first reaction was "somebody who has finished the docker tutorials should easily be able to make a Go container, what's the big deal?". But, this is targeted towards Go people and not necessarily Docker-Go people.
The only thing I could come up with is maybe you have additional dependencies outside your binary required to make the environment run?
I've been looking for a good reason to use Docker, but I'm not seeing the benefit given my Go based environments. If I need fine grain container-like control FreeBSD Jails have been working just fine for me.
If not, why is this significant or different?
It really isn't "significant" -- it's just stringing together docker containers and the Google Cloud as a demonstration of how quickly someone can deploy a Go service. It's like the old Rails scaffold.
Like Rails scaffold, this isn't enough on its own. There's many concerns for putting something on the open web and making it ready for production use. But what is really slick about this is that it shows how low the barrier of entry is to containerizing and deploying apps very, very quickly.
Google Cloud is just one example. dotCloud, tutum, orchardup, and others are out there. I'm sure a self-hosted, possibility open source, solution will be on the way a la openstack.
The benefit of containers over clouds are widely documented--but as a developer it means FAST phoenix servers that mean I can iterate on deployment orchestration, configuration management, etc.
It's as significant as someone putting up an example Rails Docker image, except that official base images with Go have just recently been released.