"systems language" and "systems programming" are terms whose interpretations vary widely across the industry. At one extreme, it means kernels, drivers, and embedded, the stuff where you need to precisely manipulate bytes with no infrastructure and minimum overhead. At the other extreme, it means any software whose users are other programs rather than people, so API services and so on. My first job was as a "systems engineer", writing database middleware (kind of) in Java.
Go is not suitable for the kernels etc kind of systems programming, but it's highly suited to the API services kind.
In fact, the terms are becoming more and more diluted. "Systems Engineering" is a good example; it actually used to be a well defined discipline (see EIA-632, IEEE 1220, ISO 26702, etc.) until some non-US universities started to use the term for disciplines like system administration or computer network engineering. Similar confusion e.g. exists on the question of whether C is a high- or low-level language. The funny thing is that Go is even used as a low-resource embedded system programming language, e.g. for the micro:bit.
Go is not suitable for the kernels etc kind of systems programming, but it's highly suited to the API services kind.