Most of the underlying issues can be usefully explored with a single example, such as the printer. Alice doesn't really want the lpr(1) to block until Joe finishes printing out his thesis. The system doesn't want Alice deleting her file before it's printed. The obvious solution is to place a copy of the file in a spool directory until it's safely on paper.
Traditionally print jobs were queued in /usr/spool/lp. The problem, as noted, is that this effectively prohibits mounting /usr read-only. Keep in mind that the issue extends to every queue (mail, uucp, etc) and all of the system logs. This causes a secondary problem, namely that the size of /usr is totally independent of the size of the operating system install. Imagine you're provisioning a new system which has 35MB of binaries. How large do you need to make the /usr partition? Trick question! 35MB plus required time to retain logs times the average use of email, printers, newsreaders.
Moving everything to /var neatly solves the read-only issue, and makes significant inroads on the administrative nightmares. For one thing it allows easy measurement of how much space that data is using. It's also quite a bit less painful to extend or replace one single partition than worrying about /usr/spool, /usr/log, etc.
Storing system state spread amongst home directories buys you nothing but increased complexity. Instead of a single, global directory to manage permissions on you have possibly hundreds of individual ones. On top of that you can add the overhead of continuously scanning through all those directories.
Less obvious is the fact that home directories are not system specific. Network mounted ones are fairly common. Chances are when printing a file you only want it printed where you're logged in, not every machine your home directory is mounted on. Availability is an issue here too, as home directories can vanish if the file server craps out. Or to add a more modern twist, if the home directory is encrypted and the system can't read it.
Historically global storage has served as a cache for public information. In the absence of a news server usenet articles were downloaded in batches and stored in a central location. After all, there's no reason to duplicate the large news feed across multiple users. Centralized queues also serve as a buffer for incoming information. Consider the mail queue, which may not be able to deposit mail into your encrypted home directory. (Availability again) Or the case where you get a ton of spam while away on vacation. Should the system discard all messages after you exceed your disk quota, or save them and let you sort it out later?
