it's not that gcc was less buggy. There were bugs in the gcc ports, too.
In my particular case (Convex), gcc would generate faster scalar code than the for-pay 'vectorizing' compiler would. This was very popular with the technical marketing folks (who would attempt to 'win' benchmarks in order to sell computers.) I pointed this out to the compiler group, and suggested that perhaps some emphasis on scalar code generation would be a good thing. (Amdahl's law, anyone?) I was ignored. At one point I threatened to put a trivial instruction scheduler in gcc, as gcc in those days didn't have any instruction scheduling, the Haifa scheduler didn't come about until the late 90s. Doing so would have probably beat the convex compiler at all but embarrassingly-vectorizable codes (and those were normally written in Fortran anyway.)
gcc still doesn't have a proper control flow graph, which is essential for interlock scheduling.
After I left (for Sun) it became cause for termination to use gcc in a customer-facing benchmark at Convex. As it turns out, the manager of the compiler group took offense. I was only trying to help.
Michael Tiemman made an ovation about a job at Sun (working on gcc) based on that work. Yes, Sun was supporting the gcc work even as the compiler group was "unbundling" the for-pay compiler.
gcc was basically an example of filling a need. There was a good-enough compiler available that could be ported to new architectures.
These days we have llvm/clang, which is architecturally cleaner, and which I expect to eventually eclipse gcc.