"Systems programming" isn't limited to OS kernels. I'd call, say, the Coreutils programs "systems programming." But it'd make perfect sense to implement those (or things like them) in Go†. And that's the niche I see a lot of modern Go software addressing, too: simple new OS-packagable CLI utilities, able to be written with less gotchas than if they were written in C.

† I say this because we already have an alternative to GNU Coreutils for memory-constrained embedded systems, in the form of Busybox. If Coreutils had to "serve two masters"—be both powerful at scale on big multi-core systems, and functional on tiny embedded boxes—then Go would make less sense. (Rust would be pretty good for that, though. See e.g. ripgrep.)