golang を docker で build する意味に関してはいくつかある。

vendoring tool （依存パッケージのバージョン含めた管理）の代わりにセットアップされたイメージを用意するという方法。
最近は golang から dep という公式ツールが出て今後の方針が見えてきたとはいえ
テストなどを考えると vendoring の処理自体を毎回するとか面倒なのでコンテナ使うのは悪くないと思う。

ほかは cgo の問題（golang の中で c をインラインで書ける機能）。
golang の net/http はそのままで名前解決の部分が libc に依存しているので build 環境に左右される。
これは debian などで glibc 環境で build したイメージが glibc へダイナミックにリンクされてしまい
Alpine の musl libc で起動できないという現象（または逆）がある。
net/http の場合は CGO_ENABLED=0 や -a オプションなどで golang での実装へ回避できるが、
mattn/go-sqlite3 など中身は C のライブラリへのリンクしか無いと言うものが結構ある。
mattn/go-sqlite3 場合だと動作環境に sqlite のライブラリを入れるか
ldflags などを工夫して static バイナリをなんとか作るかという面倒なことをする必要がある。
docker イメージならライブラリ突っ込んで置けばいいので楽。

あとは、コマンドの統一。
いろいろなコマンドを docker run hoge 的に統一できるということ。
docker hub に登録しておけばどの環境でもこのコマンドで取得して実行できる。
golang の場合は容量的に空のイメージである scratch イメージを base にバイナリ放り込むという感じかな。
これを頑張ってる例としては whalebrew。