When is using --package-handler=git_drupalorg appropriate with drush? In which situations are using 

drush pm-downlaod --package-handler=git_drupalorg ...


appropriate?

For example, if I am developing a normal site and want to version it with git, I assume it just best to just use the normal drush commands and version it outside of git?

Would using the git package handler, especially when combined with submodules, be most appropriate with sandbox environments where I may want to contribute patches and/or push changes back to git.drupal.org?
The second half of your question is easiest to answer: yes, if you are planning on creating a patch for drupal.org, --package-handler=git_drupalorg is a good option to use, as you may then easily create patches with git diff.  For an additional tool to help create and apply patches, see drush_iq.

The answer to the rest of your question is more subjective.  How you download projects for inclusion on a production site depends on your strategy for managing your code.  There are many options, but it's important to pick one that will work for you, because Drupal will commonly WSOD on you if you miss-match your code and your database -- that is, you must use any particular database snapshot with the version of the code that created it.  If you ever end up with an older database with newer code, you can just run updatedb; however, you can never use a newer database with older code.

Sometimes, I check in my entire Drupal source code tree into git.  When I do this, I do not use --package-handler=git_drupalorg to download modules; I just update them with drush pm-updatecode, and commit the result to my repository after testing.  When I do this, sometimes I deploy with git (git pull on production), and sometimes I keep my .git files on dev/stage only, and push just the code to production with drush rsync, leaving the .git files behind.

Using submodules might be a viable option.  There is a project to help manage Drupal submodules in your repository:  see Drupal on Git, aka "dog".  I don't really use submodules or dog myself yet.

Another option is to build an installation profile from your code, and commit just that to your repository.  The advantage here is that there's less in your repository, and it is easier to understand how versions change by tracking a makefile than trying to parse and understand the history of an entire Drupal tree committed to a repository.  See http://drupal.org/node/1368242.  I am just starting to use this, and have not really adopted it as a standard practice yet.