I disagree with you in that, only system software should be installed by the native package manager. Everything else should be AppImages.
The stuff that updates when you update the OS.
On macOS, the software that’s not an optional package manageable through the App Store (even if installed by default) or managed by Homebrew or what have you.
You know, the system software.
I.e. If I want to set up a script that makes Libreoffice trigger phone calls through a bluetooth modem, I should be able to. Otherwise it isn't really a computer. These "system" vs "non-system" almost always end up down this slippery slipe, and avoiding it is one of the reasons I enjoy desktop Linux for all its brokenness.
I've made up half a dozen definitions for it before asking, and none of them were a good guide to decide about the software on my machine. Yours seems to focus on the DE components, what is both way too restrictive (why are `ls` or `test` out?) and way too inclusive (my DE installs with an Earth rendering and graphic calculator, my workplace's DE installs with CandyCrush).
It is in fact applied by organizations, and they manage fine, so lack of a universal definition isn’t a hindrance.
If you want to guarantee certain versions of ls or test are available for the duration of the supported life of an OS, yeah, they’re part of the base system. This kind of arrangement is very nice for both users and software vendors. The base-system instability of an Arch or a Gentoo (rolling release), or the ancient productivity-software packages of a Debian, aren’t the only options—lockstep-release stable base system and rolling release user packages are an option.