If there's only one copy of a program running, it won't matter - but if you are running hundreds of copies (even docerized and stuff), you are likely better off NOT upxing.
I don't think people care about that nowadays, seeing how popular Docker containers are. I think Docker containers already make it so that you cannot share executable memory between different containers because each one runs in its private namespace.
More specifically I wouldn't expect "free -m" to produce different result depending on the namespace it's run in.
Why is this exactly?
It is rarely a big loss, because executables that are in use tend to remain in memory if the program is actually active. If you have a 300MB demon that sleeps, though, you will likely notice a swap out to magnetic disk.
That doesn't work for UPX because each execution decompresses anew, which makes it a "new executable" from the OS' point of view. The only thing that would help is kernel space merging, but that's really only activated for some virtual machines.
And even there, it's a security threat, since it enables cross-VM timing and other attacks.
(a) go compiles static binaries which makes UPX especially effective, unlike e.g. common C and C++ projects with their hundreds of .so/.dlls ; Delphi/FPC and Nim or the other two ecosystems that share this trait, but neither is as common as go.
(b) it's not good for non-static binaries, that is C#, Java, Python have no benefit from this.
(c) At the time I posted it, there were already 3 or 4 posts extolling the virtues of compressing Go executables.