One neat thing about Go that makes it superior to a shell script is that it compiles a statically-linked binary. One self-contained file! Or N if you support N platforms. Did I mention that cross-compilation is trivial?
As someone who once inherited a static binary (without debug symbols, gotta save those few bytes) that should have been a shellscript: Please don't. If your logic reasonably fits into a shell script, then put it there.
Posix shell-compatible scripts will also likely work on all platforms where you go program would've been run.
> Posix shell-compatible scripts will also likely work on all platforms where you go program would've been run.
While I see your point, writing a Posix compatible shell script is not trivial. Little errors creep in that "work on my machine" because /bin/sh is a symlink to /bin/bash, but break the script when someone runs it on macOS.
In my experience, you get a lot of cross-platform compatibility when writing Go for zero effort.
I mean this entirely depends on how things are done where you work. I wouldn't think the back-reference is necessary if all projects have their own repo in some central location (and it's trivial to match the binary's name to a repo).
Posix shell-compatible scripts will also likely work on all platforms where you go program would've been run.