if you believe shell scripts are hard enough to write that systemd can take over. Then you should also believe that they're hard enough to inspect that you want some level of auditing.
RPM's are inspectable, signed by default and integrate better with your system. (the same is true of apt). And if they're in the package repository then there is a maintainer who is ultimately responsible for ensuring the quality of the code.
For the second time here, I'm not dissing package managers... I even explicitly said the solution is "vetting a package with a high-entry-bar distribution".
But the whole point of high-entry-bar distros is that it's highly curated. Some random script from the web will not be in there. How do you serve those that need to casually distribute trivial software?
There's some answers to that question - they're not widespread at all. It's one of the major failures of package management on Linux. macOS gets it mostly right.
Are you claiming that macOS has better vetting of its packages than Linux? And what do you mean by "Linux" anyway? -- lumping RHEL in with ADistroIMadeInMyGarage is a bit odd.
Well, linux doesn't have adhoc package management.
Because there is no standard packaging format between distributions, the best people can do is release a deb that may or may not work on either debian or ubuntu. Or an RPM that may or may not work on RH/Fedora. Or a tar.gz that will contain sometimes source code, sometimes a binary, and if it has source code there's no clear way to compile it, if it has a binary there's no clear way to install it.
So instead, curl sh.
It's pretty ridiculous that it's still a problem, tbh. What we need is somebody with the right political clout at either RH or Debian to sit down with devs of the other, come up with a decently generic solution that fits both systems and a backwards compatibility policy. It doesn't have to be perfect nor the best, it just has to be good enough to support the use cases of most Linux distros.
Once both Debian and Fedora support it, Ubuntu (and its many flavors) and Red Hat will follow. And if it's a generic enough system, with a pluggable-enough backwards compatibility policy, it's not unlikely for it to be adopted in more minor distros. If it's sold correctly, distros will gladly adopt it - we've all been waiting for this a long time.
I guess I do not understand the manner in which you use "ad hoc" to refer to package management.
It seems as though you are now talking about cross-distribution package management. It is further confusing that you are contrasting all "Linux" to the single distribution macOS.
To me the term is "ad hoc" current w.r.t. NixOS , GNU Guix and other purely functional systems, and there the distinction is made between:
1) declarative -- in which a rebuild of the system will ensure the package is present and configured as expected; and
2) ad-hoc -- in which the user can affect all of the system with side effects and rebuilds will not result in the same state.
Why would you want to allow users to randomly and aribitrarily affect all of the system and end up in an unknown state? Isn't that exactly what curling shell scripts achieves? And what method does macOS implement in order to avoid this?
If all you're talking about is cross-distro package management then you and your users can either give up on this and standardize on one OS and just pony up the cash for RedHat (same as you do for macOS) or else start writing Flatpaks.
RPM's are inspectable, signed by default and integrate better with your system. (the same is true of apt). And if they're in the package repository then there is a maintainer who is ultimately responsible for ensuring the quality of the code.