Question: a few weeks ago, we setup a cronjob that wipes the entire contents of /tmp every Sunday at 5am. I wasn't really convinced that this is a good idea. Today we discovered that a certain task depended on an existing directory inside /tmp - the task was broken, and worse, it remained silence about why it failed. The question is:

Is it generally a bad idea to just wipe out /tmp?

Answer: 
It's not a bad idea to do something about stale old files in /tmp, but I'm not sure that nuking the contents is the best thing you could do.

My CentOS servers use something called tmpwatch, which runs daily and can be configured to remove only files that haven't been accessed in a certain period (30 days is a popular delay), or modified in a certain period; it can be told to leave directories alone unless they're empty, or not to touch directory files at all, or to exclude files used by a certain user (root is a popular choice).

This works well for me, and it offers enough hooks that you can tune it to do what you want. I'd recommend tmpwatch, or whatever your distro offers that's like that.
It depends a bit on applications and distributions. It's typically safe to wipe /tmp on reboots. Wiping it on a running system is very likely to break applications. /tmp is not meant for permanent storage, and any application using it for such is serious broken, but applications can easily leave files in /tmp for months on a system that stays online. Which is why I am a bit suspicious about tmpwatch. 

In the end I only tend to look into how much is stored in /tmp when a server is running low on hard disk space. If there is plenty of HD space why bother?