One benefit is that they were able to bootstrap the language and now enjoy having a pure Go toolchain.
Whereas with LLVM, while they could benefit from all the work that has gone into it, they would get a dependency on C++ for life.
This way, the progress is slower and multiple releases will be required to achieve some optimizations, on the other hand it is the only way to prove to naysayers that for the systems programming use case of writing compilers, Go is also a viable option.
It's not based on LLVM. I don't know how recently the official FAQ was updated, but they say [1] that while they thought about using LLVM, they thought it was too large and slow for what they were looking for.
There are llvm (and gcc) implementations of go but main/reference implementation was written from scratch in C and later moved to pure go. IIRC the authors wanted to achieve really fast compilation and a few other things that required them to start from scratch.
There was also the matter of figuring out llvm in order to use it. The initial Go compiler was based on the Plan 9 C compiler toolchain, which the designers of Go know well.
One of the other reasons relates to how stacks are handled for goroutines.
Whereas with LLVM, while they could benefit from all the work that has gone into it, they would get a dependency on C++ for life.
This way, the progress is slower and multiple releases will be required to achieve some optimizations, on the other hand it is the only way to prove to naysayers that for the systems programming use case of writing compilers, Go is also a viable option.