I usually avoid rebooting as a matter of principle. It always seemed like using a hammer to swat a fly, and the inferiority of an OS is directly related to the number of reboots required to get it to function civilly. That being said, I've run into a number of situations during my OS X re-installation where a reboot was quite necessary.

The first involved an application called TextExpander - a great little app that performs macro expansion at the OS level for all applications and meshes well with QuickSilver and Ubiquity for Firefox. The beauty of these applications is that almost everything is accessible via the keyboard as opposed to having to switch input methods (the old keyboard, mouse conundrum). This allow you preserve flow when you are working without being distracted by the cognitive changes required to switch input methods.

Anyway, the problem I experienced was with the way TextExpander choose to install itself. Although the instructions are pretty straight forward, nothing in the installation docs mentioned the application's requirement of a custom daemon - textexpanderd. Unfortunately, the installer, while correctly copying the daemon onto the System, failed to enable the associated Login item. The system logs provided the very unhelpful messages consisting of the following lines :

Nov 10 18:57:31 aleph kernel[0]: Finder[109] Unable to clear quarantine 
`TextExpander.prefPane': 30
Nov 10 18:57:37 aleph [0x0-0x1a01a].com.apple.systempreferences[188]: 
No matching processes belonging to you were found
Nov 10 18:57:38 aleph textexpanderd[191]: textexpanderd 2.5 
at your service

Luckily, I managed to decipher this gobbledegook, and a handy reboot allowed the daemon to start without issue. It is documented here for others who might one day run into the same problem.

The other situation I found I need to bounce the machine was with the installation of PostgreSQL. In my orginal instructions, I outlined the steps to create a user account using the dscl command line utility. I unfortunately forgot to include the caveat that a reboot is required to make the user account visible to the system. Yet again, a less than insightful error message was displayed when attempting to initialize the database. I've lost the message, but the gist of it was the inability for postgres to proceed with the initialization because of inadequate shared memory configured on the system. This, needless to say, is not one of the limitations of my machine. Note to self: if the user is not visible from the User dialog, but available from the terminal, this is the issue.

Oh well, such is life.