What do you propose instead? So far package management solves these problems for me:
1. Upgrading the entire OS at once.
2. Easy updates.
3. Almost never having any issues with incompatible software. When issues arise I can easily roll things back or wait until they are fixed.
4. Never having to hunt for software on the web.
5. Ability to script server/workstation deploys.
6. Never having to spend more than 5 minutes on maintaining my workstation.
That last point is huge. How long would it take you to update Java, Flash Player, Adobe Reader, IE and install SP# on Windows?
If there is an alternative way of approaching it I'd be very happy, since it can only be an improvement upon already stellar apt/yum/BSD ports, etc.
I'm only speaking to the dependency-resolution function that makes package management necessary on certain OSes. Public application repositories sharing a standard interface still have some nice features.
But if the applications are all statically-linked, I don't have to worry about dependency conflicts, and some things are a lot simpler, e.g. copying the binaries off to a flash drive to take them to another system, or running two different versions of the same software simultaneously.
On Windows, I don't usually even run installers anymotre; I extract the installers, collect all of the dlls into the application directory, and compress everything with UPX. Once the program is running out of a self-contained directory, I can run it off a thumbdrive, copy it to my Dropbox, etc. Plus I have the option of not updating software when I prefer not to.
I don't really see how your approach to installing Windows applications can scale. Also, pinning will allow you to hold back any packages you'd like.
The only potential problem I see is statically-linked applications issue. However, I think in the case where libraries are open and shared amongst many applications/other libraries, it makes no sense to use static linking. Its advantages are that you don't need to worry about dependencies but that "is a solution to a problem that doesn't need to exist in the first place" since package management takes care of these issues.
IMHO it's better to spend 30 minutes once a year resolving an issue that arose when a Debian/Ubuntu repository got screwed up for a short period of time, than to constantly try to solve the problem of managing software installation/upgrades.
Under Windows and OSX, statically-linked or self-contained packages are indeed the only way to stay sane when deploying an application.
However, this comes at a price: You'll always have to provide a newer version of the application whenever a serious issue is fixed in one of your dependency libraries. This means extra work for you. Also, you'll have to take care of an auto-upgrade mechanism.
On systems with a package manager, you'll only have to provide updates if you fix an issue in the application itself. You also don't have to write an auto-upgrade mechanism. Just upload a new package to your server.
However, if you don't care that much about users' security, statically linking is indeed a lot less work than using a package manager.
(FWIW, I'm the maintainer of Mingw-cross-env (http://mingw-cross-env.nongnu.org/). This is a project that provides a cross-build toolchain for statically linked Windows applications. It builds a cross compiler and lots of free software libraries. We have that kind of discussion from time to time on our mailing list.)
If there is an alternative way of approaching it I'd be very happy, since it can only be an improvement upon already stellar apt/yum/BSD ports, etc.