If you can afford using a package manager then you can afford using something more sophisticated than bash.
The whole point of bash is that it’s ubiquitous: be it an air-gapped embedded system, a recovery image or a full desktop environment, you can count on it having either bash or something reasonably close, no strings attached.
Introducing a Rube Goldberg package manager would go against this.
I can see in the use case of building up scaffolding between many different Unices to a common reference point sufficient to serve as an abstraction layer for a packaged software product to code against a generic Unix model, a Bash package manager might be useful. Some of those Bash-based abstraction layers can get relatively sprawling, and a packaging system would serve a useful role as a configuration dispatcher.
Instead of a bewildering array of case/if statements for each architecture/distro in every script, the package manager stores and deploys the platform-specific scripts, and make reading/maintaining them more streamlined. Then your case/if selection of the platform-specific environment is centralized into a single centralized location where the package manager call for installation is made.
I agree however that in an in-house setting, if I had the choice to use a package manager, then I'd be choosing a language other than Bash.
The whole point of bash is that it’s ubiquitous: be it an air-gapped embedded system, a recovery image or a full desktop environment, you can count on it having either bash or something reasonably close, no strings attached.
Introducing a Rube Goldberg package manager would go against this.