I guess in the sense that you only need the Go toolchain, rather than also needing a C toolchain to compile+link an extra C object file into your binary.
IMO, it's playing fast and loose with that term, but I guess the point is that it's not using CGO (i.e. calling into C code). It is, however, using the assembler packaged with the Go tools, so in that regard it's not "pure" go.
The terminology in this context is already fast and loose: It is rigorous in a practical engineering sense and is far from a mathematical level of precision. As I pointed out above, the maintainers could just define Go to include a few Assembly languages.