Sure.
>I would have thought that any language with an explicit compile step would be at a disadvantage in this space.
Not exactly, and not always. In fact it can be the opposite. It depends on a few factors, and there are tradeoffs.
Consider that so many of the command-line utilities that come bundled with Unixen (Unix, Linux, BSD) are written in C - just look in /bin, /usr/bin, etc (some of the default dirs in $PATH). (Do a "file * | less" in those dirs.)
(Though there definitely are utilities that are written purely in *sh, or Perl, or Python, and more so these days than some years ago. Still, some, particularly shell scripts, tend to make calls to compiled utilities such as sed, awk, grep, ls, du, df, ps, and many other commands.)
For utilities used often or heavily, or where performance is important, a compiled binary can often be a good choice: lower startup time (don't have to start the interpreter to run the script, often faster run time (because running compiled machine code vs. interpreted or JIT'ed).
Go has performance closer to C than Python does, and also has some aspects of HLL's (High Level Languages) like Python. The compile only has to be done once per machine or platform, remember; also, Go compilation is quite fast, which was a design goal of the language. And if you compile once on one machine, you can just copy the binary (in an automated way, too) to any number of other machines running the same OS and version. With a self-sufficient binary, you avoid both the issues of missing or incorrect dynamically loaded libraries of languages like C (if the C program uses them), and the issues of missing or wrong versions of required libraries, with languages like Python.
Those are some reasons I could think of, off the top of my head. There may be others, both pro and con.