BENEFITS OF PACKAGING SOFTWARE

• First, having a piece of software allows you to solve the problems the piece of software solves. Because software generally solves a variety of problems, and most software systems solve different problems, i.e. most software systems have some dozens of competitors at most, by installing more software, you increase the number of problems you can solve, simply by providing a portfolio of solvers for different problems, without the need for software to interact or compose at all.
• Secondly, there are problems whose solution is distributed across the programs, i.e. takes more than one program to solve (think UNIX command line tools like cat, |, sort etc, but not limited to those types). If you have N programs, the number of pairs of software (N * (N - 1)) / 2. This grows with the square of N, so there are O(N^2) possible combinations of software leading to the possible of solving more distributed problems. Furthermore as you consider n-tuples of M systems, the number of possible combinations increases dramatically. Therefore even one extra program dramatically increases the number of potential distributed problems you can solve.
• Installing software from source is error prone, and not a skill that the general public has. So not everyone can do it. If there is no package available, some people will not be able to use the software, nor any software that depends upon it.
• Having software packaged allows people to build reliably on that software, because the configuration is the same
• It takes time to read the installation instructions, install the dependencies, compile the software, and so forth.
• Being able to easily install software allows you to install more software than you would otherwise, simply because of the concern of time.
• By having more software installed, more dependencies are satisfied, allowing you to install still more software, in a virtuous cycle.
• If you have M packaging systems, and N pieces of software to package, and O users, then if the software is unpackaged, you have M*N*O number of installation attempts, each of which takes time, effort, skill and is error prone. Whereas if you package, you have only M*N number of packaging attempts. Given millions of users, that is a vast reduction in time, effort money and so on.
• Packages allow you to stably build on things. If you have the prerequisite packages installed, your software can call that software and make use of it.
• There are numerous (almost limitless) virtuous ways for software systems to interact / compose. They can analyze each other, they can invoke each other, they can share data, they can wrap each other, the can serve each other, they can include each other, they import each other. Bridges enable communication between systems.
• Since most software solves orthogonal problem sets, by having a vast number of software systems installed on the same computer system, or available to other computer systems, by making a comprehensive packaging you dramatically increase the number problems that those system can solve. As with genetics, most information is carried in rare alleles. So rare programs offer rare problem solving abilities which constitutes the bulk of problems.
• When you don't package software, bitrot causes the software to be unable to be installed, due to missing links. Thus it is impossible to build the software and have an executable. Therefore packaging serves archival and legacy systems maintenance purposes.
• Once packages are made, if you need to reinstall the software, it is instantaneous. You need not build it again on a different machine. Thus, if you have P machines to install on (on average), you have only M*N versus M*N*O*P
• When hardware fails, having packages is a clean and reproducible way to rebuild the exact same system, which you know will have the same capabilities, because of the determinism of the build process. So it is possible to recover / rebuild systems entirely the same.
• Per Chaitin's Information Theoretic Limitations of Formal Systems, program size is an upper bound on proof-theoretic capability with respect to set inclusion. The number of problems a system can potentially solve grows superrecursively with respect to the size of system, and there is a superrecursive speedup in the potential time it takes the system to solve any problem with respect to the system's size. A superrecursive increase is faster growth than an exponential increase, and even faster than the growth of Ackermann's function or (I think) a Ramsey function, since they are all nevertheless recursive functions.
• By having reproducible builds, it becomes possible to build systems with repeatable interactions.
• The additional problems the system solves allows you to progress to even more problems to attempt to solve, which, if your system is (meaningfully) larger, has a greater probability that it has the solution to those problems.
• Collecting solutions to problems before they occur is provident. One problem is finding the right solution to problems. There are programs that solve the problem of finding the right solutions to problems.
• By having a comprehensive set of packages available, programs that rely on them will not be missing functionality, which would hamper their operation
• By making packages, new functionality can be distributed to the end user faster than it otherwise could, making software development proceed even faster, and solving more end-user problems.
• The problem of packaging software itself can be made less odious by the packaging of software that aids in various ways in making packages.
• By having increased and reliable automation, you increase your productivity, leading to the creation of more software, which can do the same, in a virtuous cycle.
• The reproducibility of builds allows you to do dev ops more effectively, by generating Chef or Puppet scripts, bash scripts, Docker builds or Vagrant provisioning scripts.
• By having packages, it becomes possible to assert things about that specific piece of software in bug tracking systems, to aid in resolving the problems. By having packages, you can run regression integration tests where the only variable is the different version of the package
• Having more software packages available by default, and packaged tools to guide the user, prevents people from rewriting that functionality for that particular environment, thus saving reinventing the wheel, and also preventing unnecessary duplication of effort and teams, which would prevent other software from being written.
• By having packages, you enable systems to be installed / brought up in minutes rather than days.
• Since software system interaction increases "information fusion", you have tremendous improvements in the capabilities of systems when hundreds of thousands of tools are installed (trying to make hundreds of thousands of packages (without automation) really is not achievable in one's life, speaking of moving a mountain with a teaspoon)
• Why would one want to have hundreds of thousands of tools? If one does not need them, there is little lost except hard disk space, one might even decide to uninstall them or not install them to begin with. But if you do need the system, having the ability to install it and use it can be critical or even life-saving in certain cases.
• Existing tools have ecosystems which work together, such as Info page documentation working with Info readers. When the software has not been designed to interact with certain other software, tools exist to encapsulate and wrap that software, exposing its APIs
• The software you install can be used as data to machine learning algorithms, to help them to learn how to write software. The packages can be used to train systems to make packages.
• The more data and datasets you have installed on a computer system, the more Machine Learning can be employed. Data is viewed as part of the program, from the point of view of Algorithmic Information Theory.
• Not every system must install the same software, if, for instance, you have networked software. Having packages available makes it easier to build heterogeneously capable systems which can interact with each other, conforming systems to certain social "roles", such as a file server or not, and you can form social patterns by connecting systems with different roles in different ways.
• Many people have individual itches they wish to scratch, and not everyone has the same itch. Repositories such as ghtorrent track sites like GitHub. Having tools that help to automate packaging of software makes it easier to roll packages of whatever kind out of software on GitHub. The various configuration systems used by software can be modeled in the automatic packaging tools, and the automation enables developers to build more efficient packaging tools with wider coverage, thus increasing the number of systems able to be included and speeding it up, allowing functionality to get to the end user.
• Many developers scratch their itch. An itch is a sign of an unsolved problem. If we can write down what the problem is that was solved, you can say that is a feature the software provides. By processing text descriptions of GitHub software, you can extract the problems the system solves, and give that information to a matchmaker system which finds solutions to indexed problems.
• Rather than wasting time hunting for a specific tool (possibly under time pressure), and then repeating, always conducting a goal-directed search for a tool, if you just stop looking and collect everything, you're much more likely to be able to find any tools you need (on your system) if they've all been packaged and integrated.
• With packages you can try out more software, more quicly.
• It's much, much easier to uninstall packages, since many package managers have clean package removal abilities, then it is to remove software that has been installed by things like `make install`.

I am just getting started, will add more later.