What are the counter arguments?

Run htop or similar, sort by "shared memory" column and see how much more memory you'd need per process if shared linking did not exist.

I think the author's using a wrong method to make a point. Dynamic linking feels out of place for most long-running server-side apps (typical SaaS workload). One can argue that in a mostly CLI-environment there's also not much benefit.

But even an empty Ubuntu desktop runs ~400 processes and dynamic linking makes perfect sense. libc alone would have to exist in hundreds reincarnations consuming hundred+ megabytes of RAM and I'm not even talking about much, much heavier GTK+ / cairo / freetype / etc libraries needed for GUI applications.

Go executables are statically linked. It makes deployment a breeze.

I think you overestimate how much saving you get from dynamically linking libc. Each executable uses only a small portion of libc, so the average savings is going to be in the handful of kilobytes per executable.

In theory yes. However, in practice static linking with glibc pulls in a lot of dead weight, musl comes to the rescue though:

test.c:

  int main(int argc, char **argv) {
    printf("hello world\n");
    return 0;
  }

  $ gcc -O2 -Wl,--strip-all test.c
  $ ls -sh a.out
  8.0K a.out

  $ gcc -O2 --static -Wl,--strip-all test.c
  $ ls -l a.out
  760K a.out

  $ musl-gcc --static -O2 -Wl,--strip-all test.c
  $ ls -sh a.out
  8.0K a.out

    jart@debian:~/cosmo$ make -j12 CPPFLAGS+=-DIM_FEELING_NAUGHTY MODE=tiny o/tiny/examples/hello.com
    jart@debian:~/cosmo$ ls -sh o/tiny/examples/hello.com
    20K o/tiny/examples/hello.com