Even with all that said, operating system packages require a vast amount of testing, development, and patching, constantly, even within those small parameters. Packages feel easy because potentially hundreds of hours of development and testing have gone into that package you're installing now, on that platform you're on now, with the components and versions you have now.
Kubernetes "packages" aren't really packages. They are a set of instructions of components to install and configure, which often involves multiple distinct sets of applications. This is different in a couple ways: 1) K8s "packages" are often extremely "loose" in their definition, leading to a lot of variability, and 2) they are built by all kinds of people, in all kinds of ways, making all kinds of assumptions about the state of the system they're being installed into.
There's actually multiple layers of dependencies and configuration that have to come together correctly for a Kubernetes "package" to work. The K8s API version has to be right, the way the K8s components are installed and running have to be right, the ACLs have to be right, there has to be no other installed component which could conflict, the version of the components and containers being installed by the package need to be pinned (and compatible with everything else in the cluster), and the user has to configure everything properly. Upgrades are similarly chaotic, as there's no sense of a stable release tree, or rolling releases. It's like installing random .deb or .rpm or .dmg files into your OS and hoping for the best.
Nothing exists that does all of this today. To make Kubernetes packaging as seamless as binary platform-specific packaging, you need an entire community of maintainers, and either a rolling-release style (ala Homebrew) or stable versioned release branches. You basically need a project like ArtifactHub or Homebrew to manage all of the packages in one way. That's a big undertaking, and in no way profitable.