Drupal best practices encourage storing all non-core modules in "sites/all/modules" directory. But a little additional effort will go a long way in keeping your site's code organized, whether you're a site builder or a Drupal developer.
I prefer to create four separate directories to store my modules in:
Store all downloaded Drupal community modules such as Views, Rules, or Pathauto in this directory. You know that if it's in this directory you can update the module with minimal effort. The contrib modules should always be strictly downloaded in support modules. They should also never be edited while in this directory. This becomes important when it's time to perform security updates on them.
If you're a Drupal developer and you'll be writing some custom code, store all custom modules in this directory. With the custom modules in a separate location from the contrib modules, it is easier to navigate to the code that is most likely to change. Additionally, it flags the module as fair game to add custom site code to.
Features are just modules that you generate from your database settings (using the "Features" module—surpise, surprise). Keeping them in their own directory is a handy way to ensure you know where to put that Feature update. While this is more of a side note, I also encourage placing the word "Feature" in the package of any Feature. Features should be enabled on the Features page and it will make it easier to not get confused.
If for some reason you need to patch a contrib module, drop it in here with the patch and some notes so you will know how to update the module later. For example, the Views module has a patch that allows arguments to set the value of exposed filters. If I really want that patch on my site I would move the views module from custom to patched, and then download and apply the patch to the modules. After applying the patch, I would add a "PATCHES.txt" file to the module directory explaining why I needed that patch and what it does. Both the actual patch and the PATCHES.txt file should be included. When the time comes to update the Views module I can use the node ID to track down the latest patch and re-roll it against the latest release; or, confirm that the patch has been applied to the module and move the module back into the contrib directory.
Some developers also like to create a developer directory for Drupal development modules such as Devel, Masquerade, or Admin Menu. Since this directory pretty much behaves the same as contrib, I don't generally use it.
A note on multi-site installs
Lastly, if you have a multi-site install and want to add a specific piece of code to one of the sites but don't want any of the others to be able to access it, you should you store it in "sites/sitename.com/modules". You can use that same directory structure outlined here in that modules folder if there are more than a few modules in each.