From everything I've read, by people versed in compilers, the implementation is pretty basic too (regarding optimizations, shortcuts, compiler design, etc).
In fact, the Go core team themselves have said time and again that they preferred simple implementations and implementation convenience over more powerful but complex ones...
The Go implementation has gotten more sophisticated over time. It now has an optimizing SSA backend, a rather intricate GC, etc. I still disagree with a fair number of the Go implementation design decisions, but I certainly wouldn't call the compiler a basic implementation anymore.
Having worked on the Go port for SPARC with another person (don't know if it was ever completed), I have to agree with the parent here. The implementation of Go itself (based on 1.5-1.8 when I worked on it) was actually very complex. Large swaths of the codebase were completely uncommented and much of the knowledge about how the system is intended to work resides in the heads of the core Go team.
For what it's worth, LLVM would have made precise moving GC hard. (Though Go 6g/8g still doesn't have moving GC, which is unfortunate.) For that reason, I'm not certain that LLVM would have been the best decision in the long term, though it would have made Go code faster in the short term.
In my view, if Cranelift had been around when Go was announced, it would have been the clear best choice over LLVM, due to compile times and relative simplicity allowing for easy modifications to add things like precise moving GC and moving stacks.
Yes, because we all enjoy waiting for a compiler to get its work done, while keeping the myth alive that either C or C++ are required to write compilers.
Today, perhaps. But wasn't it the case for up until 1.3 or 1.5 that a lot of corners were cut, and things were much simpler than most "commercial grade" compilers (and not just in the simple = cleaner way, but also in the lacking sense).
In fact, the Go core team themselves have said time and again that they preferred simple implementations and implementation convenience over more powerful but complex ones...