You can have ~/.config/. Nothing in macOS prevents you from having it. And so, some programs do. The worst thing that happens is that, instead of having one directoy ~/.foo you now have one directory ~/.config/foo and nothing else in ~/.config. But as soon as you add the second thing that uses ~/.config, you now have two directories in there instead of a second dotdirectory in ~.
It's just that for a bunch of them the XDG path is only used if it exists - e.g. emacs predates the spec, so it uses ~/.emacs.d (and a few others) first.
Cargo doesn't use the XDG paths at all, apparently - https://github.com/rust-lang/cargo/issues/1734. However it also needs a directory for binaries (~/.cargo/bin) and ~/.local/bin isn't actually in the spec at the moment (https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/14).
It was just an observation that there are many devs writing UNIX tools on Apple hardware. There was no snark.
Nobody stops Apple developers respecting a Freedesktop spec, but the point is many people that mostly know macOS probably didn't even know XDG was a thing. It's not like Apple encourages it in any of their command line utilities.
What I really want is an API that does "create/open/delete a file/directory for the relevant configuration/cache/resources store", be it user configured or platform default. What I get is an external package that gives me a list of potential storage locations (of which I'll probably just pick the first) that may or may not be actual directories on the system which I may or may not have access to touch files in.
Some devs are kindly reminded that there's a spec for these things but often it's too late as data is already in specific paths that users may have come to know. That way you end up with paths that get set by environment variables where you have to tell each and every program where to put their crap.
Other programs don't care enough to implement the standards (like Firefox; the bug report about XDG is old enough to vote [1] and it's still not implemented fully). Kubernetes has an open issue for its client that only ever gets bumped.
Even worse are devs that are reminded of standards like XDG and then decide to give everyone the middle finger. Snap is one of them, not only is the data directory hard-coded, it's hard-coded lowercase unlike every other standard directory on Canonical's distribution itself! Snap's biggest competitor, Flatpak, decided not following the standard is not a problem [3]. At least it's special snowflake folder starts with a period so that it's hidden by default, I suppose. Even Bash doesn't support XDG [4] because not everyone uses Linux (and apparently no effort should be made to support OS specific standards?) with the suggestion closed as won't fix.
Many tools that do support XDG only care about their own standards, of course; Windows has had SHGetKnowlFolderPath since Vista, replacing SHGetFolderLocation which dates back to Windows 2000. Still, developers like to push POSIX standards into Windows, creating .dotfiles and not even bothering to at least mark them as hidden.
There's a big list on the Arch wiki[7] listing programs and their compatibilities with XDG.
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=259356
[2]: https://github.com/kubernetes/kubernetes/issues/56402
[3]: https://github.com/flatpak/flatpak/issues/1651
[4]: https://savannah.gnu.org/support/?108134
[5]: https://docs.microsoft.com/en-us/windows/win32/api/shlobj_co...
[6]: https://docs.microsoft.com/en-us/windows/win32/api/shlobj_co...
[7]: https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcode...
Also FYI Doom Emacs is currently XDG compliant.