Just wanted to post a brief warning about expecting to be able to roll back a cumulative update or hotfix by reverting to a restore point. In short: don't do it! These two features are *NOT* designed to work together. There are various complications with this and other methods of removing a cumulative update. Hopefully you won't be in a situation where you need to remove a cumulative update, but if you do, I will go over a few things you should be aware of.
Binaries vs. Uninstall
System restore is not necessarily going to remove binaries from locations on your disk that Windows isn't deemed to "own." So what you may end up with in some scenarios is a system that has a cumulative update (partially) installed, but since the program is no longer registered in add/remove programs, there is no longer the ability to remove it correctly. Eventually this may lead to a wipe and reinstall. I strongly recommend using the CU uninstaller utility in Add/Remove Programs instead of trying to "roll back" like you might do with shareware and less complex, non-service-type applications.
Removing "old" setup files
You may be very anal about cleaning up old files from your system that are no longer needed. Lets say you install SP2 on SQL Server 2005, then you install CU5. If you install CU6, you may think it is safe to blow away the CU5 files. Hold on, tiger! If you need to uninstall CU6, it is going to hang at some point, and leave you in a bit of a pickle. What happens is it rolls back to SP2 (or whatever release/SP level you were at before applying any CUs) and then tries to apply CU5. If it can't find the install files (because you deleted them!) then you will be stuck at SP2 and I am not sure currently if the uninstall will fail and rollback, or if it will succeed and leave you at SP2 instead of CU5. I have heard that you might get the big hourglass in this scenario, and if so, you may eventually kill it — potentially leaving your system in a bad state. So, my recommendation here is, leave those installer files there. This should be a very last resort for reclaiming disk space, and with a little foresight, you should run the installers from a system other than C:.
Personally, I would highly recommend testing CU functionality on a throw-away cluster (e.g. virtualized) and doing your best to not have to remove a CU once it has been baked into an important cluster. I have successfully removed a CU from one cluster in the past, but I am sure it is not a very highly tested scenario. Both Geoff Hiten and I have had cases where attempting to install an SP or CU onto a cluster took on one node but not the other, and this made it impossible to back out the installation *or* to supercede it with the next SP or CU. Geoff found a work-around after a very lengthy process; I gave up on MS Support after several months, and resigned to rebuilding the cluster from the ground up.
In a session in Seattle today, we were told that there would be a KB article forthcoming on how to deal with rolling back SP and CU installs. When I hear about it, I will post something.