If /tmp fills up, things start mysteriously not working (a surprising number of things create temp files, including things you wouldn't expect to), so it needs to be on a partition that won't fill up. I usually put it in its own partition, so that accidentally filling up / won't bring cause mysterious problems.
/var should go on a separate partition so that the log files don't fill up the partition that /tmp is on. A server can easily generate large log files quickly, and it would be unfortunate if that caused the server to fail in weird ways at inconvenient times.
> If /tmp fills up ... so it needs to be on a partition
Makes no logical sense. When you create an (inter-disk) partition you reduce the blocks available to all remaining partitions on that disk. By reducing partition size you _increase_ the probability of all remaining partitions filling.
If you had said adding disks for /tmp and /var were indicated I might agree, but would still be wondering what kind of applications you have.
Looking back at Unix' history we see that partitioning was only added before RAID and only to accommodate additional disks. It is the failure to understand this history and rational that leads certain sysadmins to believe that inter-disk partitions accomplish anything other than reducing robustness (in absence of a badly behaved application, which is 99% of the time a badly configured server or application, per the log rotation example).
Partitioning has some security and performance gains. Different filesystems for different workload (e.g. perhaps xfs for database files and reisterfs for /tmp), mounting with noexec or ro in some cases.
/var should go on a separate partition so that the log files don't fill up the partition that /tmp is on. A server can easily generate large log files quickly, and it would be unfortunate if that caused the server to fail in weird ways at inconvenient times.