Typically, each physical user on a system has an ID, and a running process is run as the user who starts it. This means the process is able to access all of the user's files, even those that not intended for this specific program. For example, if you start running Firefox then it has access to Chrome config files, and vice versa. But as you can see this is irrational because any browser works correctly without access to another's config files.
This is also dangerous if you consider one malicious program a user starts is enough to stealthily modify all of the user's files, plus send emails to other people as the user, access web accounts if the user stores a cookie, and many other possible undesirable behaviors. The root cause is that the process is running as the user, not as itself.
The problem has been partially remedied in commodity Linux systems by specifying UID and GID when starting a process. While this is true for many system daemons, it is not the typical case for client softwares. Many utilities such as browers, FTP clients, text editors are run as the user but not their own UID.
The OS which seeks an OS-level solution is Android, in which every app has its own ID and accesses user's data through permissions. It adds some complexity but prevents a lot of attack possibilities. If this is seen as good practice, then why isn't this feature ported to desktop Linux (Or has it)? With wider deployment of
systemd, users are now having much better control of the processes they run and there shouldn't be technical difficulties in implementing such a feature.