Generally I think that the ability for individuals to upload packages and for those to be available immediately for consumption is an incredible benefit for developer productivity and pace.
I'd also agree that review steps are important, so perhaps the defaults for application-side package managers should err more towards pinning to specific versions, rather than automatic updates (with the possible exception of security-related updates).
To me there are two common modes of software distribution:
- "Building-out" phase distribution: this is while applications and the libraries that they rely on are in active development -- they're 'leaf nodes' if we consider them as a dependency tree. This is where pace and the ability to iterate quickly is beneficial. Code and dependencies are likely not installed from the OS distribution, because that may not evolve quickly enough to support development.
- "Baking-in" phase distribution: the applications and libraries are maturing and have proven their worth in multiple production environments. Stable releases exist, and may have support offerings associated with them. This is where distribution-packaging shines; it makes trusted, well-tested software immediately and easily available to a very large number of users in a way that is reliable and doesn't introduce unnecessary support burdens on the distribution packaging teams.
I'd love to see more code review at various stages of software development; we typically do it during changeset development (pull requests), but I think that pre-release code review would make sense, and I also believe that post-release 'diff' code reviews would be valuable (what has changed between v1.1 and v1.2? do reviewers agree that it is safe, correct and documented?).
The growth areas I'd expect to see in software development careers are in maintenance and review. Perhaps not hugely exciting compared to feature development, but (again, my opinion only) more important for stability and overall software quality long-term.