I think the #1 barrier to the use of packaging systems in PHP is the fact that, even nowadays, the lion's share of PHP apps are hosted on shared hosting.
In shared hosting, you don't have the ability to add system-wide packages. Good luck asking the hosting company to add arbitrary packages in any language. You might not even have a proper shell. There are a billion security issues to take into consideration when you try to access anything outside of your home directory. There's no standardization whatsoever about where to put files that don't need to be publicly accessible, though you could argue that cPanel's monopoly offers a quasi-standard. It shouldn't come as a surprise that just-upload-the-whole-damn-thing-yourself is the default method of deploying PHP packages and libraries.
You could come up with the best packaging system to use on your own server, but you won't be able to get any popular apps and frameworks to adopt it as long as those apps and frameworks need to support shared hosting customers. Shared hosting needs to be fixed before you can have a packaging system for PHP that is as powerful as npm, gem, and easy_install.
I'll only speak for Composer which is a new-ish PHP dependency manager, because I'm the co-lead on the project.
System-wide packages are a massive pain, especially on shared hosts. That's why we took the approach of installing everything local, much like virtualenv or npm do. You get your dependencies for the project, in the project. Upload, done. It comes with an autoloader to load classes and it all works with relative paths, so moving it all around is no problem.
Obviously this only handles php libraries, not apt-get packages or whatever, there are tons of great tools for managing system configuration, and we did not set out to reinvent those. But php libraries can just be downloaded, a few of them might depend on specific extensions but mostly if you have a recent-ish PHP version stuff works on most shared hosts worth their name.
As for your point on adoption, I beg to differ. Symfony which is one of the largest frameworks will use it in it's upcoming 2.1 release, I know of a few other frameworks that are looking into it, many libraries are already made available. Even major apps like Drupal have been looking into using it, not for their plugins at first, only for their own dependencies, but once they also discussed the adoption of it for plugins, and I know a few other CMSs have looked at it for just that, because it's easy to wrap into a web frontend to manage installation of dependencies from anywhere. I'd even argue you could convert an entire ecosystem if you have it all in one controlled database already, generating package metadata on the fly and installing from existing sources, then giving the option to plugin authors to start requiring other plugins and plain libraries instead of bundling everything in their code.
Composer is quite new and it's definitely not widely adopted yet, but things are looking way brighter than you picture them. Given the ease of use of publishing packages (basically you have to write one package definition like in npm, and then for a new release you just have to git tag and push to github), resistance from people should be pretty low. Please see docs on http://getcomposer.org/ if you are curious.
Thanks for the clarification. I guess I was a bit too negative in my first comment.
I'm all for composer if it's going to make library management easier at any level, either local or system-wide. Maybe if several well-known frameworks agree to standardize on composer as their plug-in manager of choice, you may even be able to obtain a de facto monopoly on PHP package management, and that'll be a good thing for all of us. (I'd love to see some sanity in WordPress plug-in management, too, but I guess that's a tall order.)
I just wanted to remind people that as long as you have to make concessions for the current state of shared hosting, you will hit limits at one point or another.
Anymore, I consider system wide package installation to be a liability, not a feature. The whole point/purpose of npm or composer is local installation. Look at the mess of Gem/Bundler and then you have to factor in that rvm and rbenv are basically designed to isolate system wide installation because of the problems associated with system wide installations.
Sure, you can get part of the benefit even if you're on shared hosting. (Off-topic but related example: I use git to manage projects locally even if they are going to be deployed to a server that doesn't support git. Last week I finally moved a small-business client to a git-enabled host, and it was such a relief.) But it's only part of the benefit.
A good packaging system, for example, will track your PHP version and extensions and make appropriate adjustments. But what if your host uses a slightly different version of PHP with a slightly different list of extensions? At best, the packaging system makes adjustments again, and you cross your fingers hoping that nothing breaks. At worst, everything breaks because your host uses the wrong version of GD or whatever.
Every shared host that supports Ruby gets mired in requests for and complaints about specific versions of gems they've installed. I don't think it will be any different for PHP.
The problems you mention are why user land components should be used where possible and wrap builtins. Install the components local to the project and you control the outcome.
In shared hosting, you don't have the ability to add system-wide packages. Good luck asking the hosting company to add arbitrary packages in any language. You might not even have a proper shell. There are a billion security issues to take into consideration when you try to access anything outside of your home directory. There's no standardization whatsoever about where to put files that don't need to be publicly accessible, though you could argue that cPanel's monopoly offers a quasi-standard. It shouldn't come as a surprise that just-upload-the-whole-damn-thing-yourself is the default method of deploying PHP packages and libraries.
You could come up with the best packaging system to use on your own server, but you won't be able to get any popular apps and frameworks to adopt it as long as those apps and frameworks need to support shared hosting customers. Shared hosting needs to be fixed before you can have a packaging system for PHP that is as powerful as npm, gem, and easy_install.