It doesn't matter what "most people use". Both compilers are equally accessible with the new go command (http://weekly.golang.org/cmd/go/). People who find their programs faster with gccgo will use gccgo, and vice versa.
Not competitive with "modern C and C++ compilers"? There are few real world programs that are improved by code generation micro-optimizations, and even for those that are Go is still competitive. http://blog.golang.org/2011/06/profiling-go-programs.html
"There are few real world programs that are improved by code generation micro-optimizations"
I don't know how to convince you of the fact that this statement just isn't true. Consider the rasterization software you're using right now in your web browser. Micro-optimizations hugely matter for blitting and tessellation. Consider video decoding (or encoding!). Using SSE instructions instead of going word-by-word or byte-by-byte makes an enormous difference. Read Dark Shikari's blog posts about x264 if you want to see how much good use of SSE matters for video encoding.
To name just one example: Modern x86 processors have an optimization that allows the fetch-and-decode step to be skipped for the second and subsequent iterations of small loops. By "small" I mean "really really small" -- something like 16 bytes is the number I've heard. By shaving a byte or two off the instruction encoding to fit a loop from 18 bytes into 16 bytes, the loop performance can double or triple. When that loop is the loop that drives alpha blending on your touch-sensitive mobile app, that can be the difference between an app that feels solid and fluid and an app that feels slow and pokey.
People use systems languages for performance. Folks for whom performance is irrelevant are all on dynamic languages, and that's not changing. Systems programmers need a compiler that knows about these micro-optimizations.
> Read Dark Shikari's blog posts about x264 if you want to see how much good use of SSE matters for video encoding.
Like http://x264dev.multimedia.cx/archives/486? "Now that I’ve written a thousand or two lines of assembly code..." etc. Programmers who know and care about these processor-level micro-optimizations use assembly code, for which by definition you do not need a compiler.
Then again if you really care about graphics performance, you're using a GPU in which case there is no compiler since the driver is just an opaque binary blob.
C compilers can and do generate SSE. Programs do rely on this code generation for performance. They fall back on assembly when codegen fails. That doesn't mean that they aren't relying on the optimizations in other places.
And a huge amount of graphics processing is always done on the CPU. Unless you're using Direct2D or something, rasterization is always done there (and even if you're using Direct2D, a lot of rasterization is still done there).
Most of the code in any program is not performance critical. Yet the reason that this is the case is that most of the time of any program is spent in tight loops. Those tight loops are what must be optimized. And that is why performance-minded systems programmers use top-notch optimizing compilers.
The popular dynamic languages have gotten away with being relatively slow because programs written in them are either not CPU bound or spend most of their CPU time in C libraries. This works great for them -- dynamic languages are awesome! But the calculus changes when you're programming in a language that defines the entire stack. When there's no C-compiled code to fall back on, micro-optimizations start to matter.
Not competitive with "modern C and C++ compilers"? There are few real world programs that are improved by code generation micro-optimizations, and even for those that are Go is still competitive. http://blog.golang.org/2011/06/profiling-go-programs.html