Just posted for my own reference - here's my workflow for updating a D6 (probably also D7) website using drush. Comprehensive information about all drush commands can be found on the https://drush.ws/ website. If you're not yet drinking the drush kool-aid, you need to—if you use a Linux server, of course.

1. Visit admin/reports/updates page on your site, read through any relevant release notes for required updates (to check if there are special requirements for said update).
2. $ drush @site pm-updatecode (add all modules to be updated)
3. $ drush @site updatedb (updates the site database - update.php)
4. $ drush @site cc all (clears all caches on the site)

The reason I do this manually, instead of running something like pm-update or pm-updatecode is that I like the granularity and security of doing all the updates discretely—especially when I'm updating a larger site, where I like to know exactly what's happening when I update.

For Drupal core updates, at least in D6, I always copy the files in by hand (even though drush can handle this), because I just don't trust Drush with that operation—especially if I have other files included in my root directory for other purposes. (Plus, using git, this is a breeze. When I used SVN or CVS, it was a major pain, due to all the 'CVS' or '.svn' directories that had to be maintained).

After finishing the drush process, I do a $ git add . , $ git add -u , then $ git commit -am "Updated , , etc." (after testing the site thoroughly, of course). Then I push the changes to production, do an updatedb on that server, and breathe a sigh of relief when everything's working perfectly.

Anyone have a better idea for leveraging drush for updates? One thing I wish I could do is maintain patches when doing drush updates on a module, instead of having to re-download and apply the patch.