Ah, sorry, I probably wasn't clear enough: you can't just count direct dependencies (or install size) when considering something's importance, you also need to consider indirect dependencies (which I think jmillikin is underestimating). I'd also argue in many cases the GNU parts have only been partially replaced, if at all (mDNS name lookups for example).
My example of mDNS is deliberate: doing a name lookup of blah.local can either go though glibc's NSS (musl explicitly does not have NSS), or explicit calls to resolved (glibc only because systemd) or avahi (non-glibc only). Unless everything calls out to avahi, you've can't rely on blah.local working on non-glibc systems.
I used imagemagick as an example (which inspired that xkcd comic) of a project which is a common indirect dependency, and vim (compared with busybox vi) to show the effect depending on extensions (you could use neovim and vim instead, but busybox was suggested as a complete replacement of coreutils). I'm not suggesting either of these are systemd or glibc only.
As to why not systemd/linux: the set of systems where systemd runs is a strict subset of where the GNU software is used, and so you have GNU/Linux systems which are not systemd/linux systems (also, systemd is linux only as far as I know, where as glibc does run on non-linux systems (Debian's GNU/kfreebsd) so it does make sense to have that distinction, where as a system running systemd could be called a systemd system with no loss of generality).
EDIT: It's also worth considering another piece of data: the author is one of the Alpine linux maintainers, they presumably wrote the article for a reason (likely bugs reports either due to people being unable to install/run specific software, or behavioural differences from GNU tools).
My example of mDNS is deliberate: doing a name lookup of blah.local can either go though glibc's NSS (musl explicitly does not have NSS), or explicit calls to resolved (glibc only because systemd) or avahi (non-glibc only). Unless everything calls out to avahi, you've can't rely on blah.local working on non-glibc systems.
I used imagemagick as an example (which inspired that xkcd comic) of a project which is a common indirect dependency, and vim (compared with busybox vi) to show the effect depending on extensions (you could use neovim and vim instead, but busybox was suggested as a complete replacement of coreutils). I'm not suggesting either of these are systemd or glibc only.
As to why not systemd/linux: the set of systems where systemd runs is a strict subset of where the GNU software is used, and so you have GNU/Linux systems which are not systemd/linux systems (also, systemd is linux only as far as I know, where as glibc does run on non-linux systems (Debian's GNU/kfreebsd) so it does make sense to have that distinction, where as a system running systemd could be called a systemd system with no loss of generality).
EDIT: It's also worth considering another piece of data: the author is one of the Alpine linux maintainers, they presumably wrote the article for a reason (likely bugs reports either due to people being unable to install/run specific software, or behavioural differences from GNU tools).