I will preface that this answer is more specifically about why
sudo has been necessary to package management.
Requiring system level privileges to complete system level tasks makes sense. Historically, Linux, coming from a Unix-like heritage, is designed with a multi-user set up in mind. To prevent user's from messing with each other and to better manage control over the system, a system administrator is empowered to be able to control and limit user's access to root or system level activities.
Here is a brief introduction of
sudo from the offical sudo website (emphasis mine):
Sudo ("substitute user do") allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments. Sudo operates on a per-command basis, it is not a replacement for the shell. Its features include:
The ability to restrict what commands a user may run on a per-host basis.
Sudo does copious logging of each command, providing a clear audit trail of who did what. When used in tandem with
syslogd, the system log daemon,
sudo can log all commands to a central host (as well as on the local host). At CU, all admins use
sudo in lieu of a root shell to take advantage of this logging.
Sudo uses timestamp files to implement a "ticketing" system. When a user invokes
sudo and enters their password, they are granted a ticket for 5 minutes (this timeout is configurable at compile-time). Each subsequent
sudo command updates the ticket for another 5 minutes. This avoids the problem of leaving a root shell where others can physically get to your keyboard. There is also an easy way for a user to remove their ticket file, useful for placing in a
Sudo's configuration file, the sudoers file, is setup in such a way that the same sudoers file may be used on many machines. This allows for central administration while keeping the flexibility to define a user's privileges on a per-host basis.
Now to get to your question of package management requiring sudo. That is not always the case. Here is a relevant AskUbuntu post covering this topic. As user Braiam points out
apt-get requires sudo because many times when installing a package you need system level access to install and write to system directories.
However as he also points out one can use
apt-get to download and install packages to locations a non-privileged user has access to. Examples include using
apt-get download or just plain old
wget to download a package to your current directory and then to use
dpkg to install the package.
The issue with this is that from an administrative stand point this is a headache. Users will be using unnecessary amounts of disk space by each having a copy of a piece of software and its dependencies, certain software can at times be malicious or behave in a manner that introduces vulnerabilities or other issues, and allowing free reign of installation does not allow one to quickly audit and update what software is on the system. Package managers allow central control and the ability to audit and trust where packages come from.
Additionally, as user Ulrich Schwarz points out, the home directories may be mounted to a partition with a
noexec flag meaning:
...it may have been difficult for you to run a (possibly CPU-expensive) binary from your home directory on a shared system even if you had access to a compiler.
I will also link to this U&L stack exchange post asking about "Why do I have to use sudo for almost everything?". I believe the answers to sufficiently back up my point in this post. You can also learn more about the history of
sudo on Wikipedia.
sudo was developed in the early 1980's to allow users to run programs with the security privileges of another user, by default the superuser (root). It additionally creates an audit trail and a role-based access control system for system administrators. Installing software on a *nix-like system is typically done via a package manager, however this is not always necessary. Package management is a system level task that administrators typically like to be able to control and audit thus it is usually restricted to facilitate those needs.