Does glibc count? If you use systemd, then you are dependant on GNU (as noted in the article). GNOME is becoming more systemd-dependant, so GNOME is also implicitly more dependent on GNU.
Other things include mDNS (what, if anything, does blah.local resolve to on non-GNU systems), libquadmath (which tends to be required more often than people would expect) or GNU-specific flags/behaviours (e.g. GNU tar just does the right thing).
I suspect if you did purge the GNU stuff (baring the things which either require you to specifically say you're fine with the result or remove required software) you'll find lots little things that don't work right, because the GNU code is functionally the only option (missing features, integrations from other software etc.). I don't think GNU is particularly special this way: try going from vim to busybox vi, or looking at how much stuff depends on imagemagick (a.k.a https://xkcd.com/2347/).
You're naming a lot of projects that aren't under the GNU umbrella. Why shouldn't "Linux" systems be called "systemd/Linux" instead? Why not "imagemagick/Linux" even?
It seems very silly to name a family of operating systems just for the C library alone. Sure, there are apps that depend on GNU extensions, but beside systemd I don't know whether the rest are really true. (Pretty sure Vim and Imagemagick work fine without glibc...)
I don't think Richard Stallman would have gone so far to attach the GNU name just because of libc. Back then when he was advocating for GNU/Linux, it was because GNU basically had a unix clone implemented and ready (libc, compiler, shell and common utilities), but people eventually named the system by the kernel, the only component that they failed to get right. At that point it was probably apt to call the system GNU/Linux, but these days when many of the original GNU parts are replaceable or faded into obscurity, I don't know whether the argument holds any more.
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).
Other things include mDNS (what, if anything, does blah.local resolve to on non-GNU systems), libquadmath (which tends to be required more often than people would expect) or GNU-specific flags/behaviours (e.g. GNU tar just does the right thing).
I suspect if you did purge the GNU stuff (baring the things which either require you to specifically say you're fine with the result or remove required software) you'll find lots little things that don't work right, because the GNU code is functionally the only option (missing features, integrations from other software etc.). I don't think GNU is particularly special this way: try going from vim to busybox vi, or looking at how much stuff depends on imagemagick (a.k.a https://xkcd.com/2347/).