OMG. What a nightmare. Of course, I'm mostly trying to build my collection of tools, so 99.8% of my downloads are applications.
As in the case of bookmarks, I can tell you that simply having accreted a directory structure (slowly over time) is *NO* guarantee that the folder structures that I used to file "Little Snitch.dmg" last time will be the one that occurs to me next time I have download an updated disc image of that app.
So how do I get past this endemic classification continuity/consistency problem?

Since my downloads are mostly apps, my strategy is to think about what the app does and then to try to constrain my imagination and terminology in terms of a rubric that I have evolved slowly over time.
Of course, not all applications are simple one-trick-ponies.
So what about the fact that some tools do *more* than just one thing? Some are freakin' swiss army-knives. This makes them hard to pin down. Its hard to assign them to just one category.
It should be pretty obvious by now that good old fashioned directory structures fall short for files that naturally seem to have multiple group membership. They force you to create redundant file structures and either duplicates or aliases(shortcuts) to co-locate a single file in all its relevant 'groups.'
Yuck.
My answer to this problem is to try to find the 'sweet spot' among the whole universe of discriminating features that might be used to categorize or classify a given application (or file for the generic case).
By way of some history (I know, I know.)... My tool taxonomy began evolving when I was still using XP Pro SP3 Tablet edition. I put all the installation files (MSO, ZIP, self-extracting EXEs) on one external USB drive, so that I could quickly get any machine I was working on 'tooled up.' In the old days, -until recently- have I had one filing system for my Windows proggies and more recently I've developed this into a taxonomy for my collection of Mac apps.
-UPDATE Tuesday, August 18, 2009 1:23:38 PM - My 2 systems have been reconciled (the old XP system has been superseded and now is identical with my Mac directory structure).
  How has this come about? Ok, well... What began as a blog post has become a major core project for me recently.
  Suffice to say, I am not thrilled with this particular project. It is not fun. In fact, it is awful. But Im trying to get through this list of irreconcilably tough 'media management' problem areas thoughtfully and carefully.
In truth, the 'FlowSpaces' project has heavily relied on the work of this 'Mindful Media Management' work and vice-versa. The core problem I allude to above was foregrounded nicely in FlowSpaces: when faced with the question of what to name each of my 12 Workspaces. The idea behind FlowSpaces is to identify groups of tools that I want to or need to use together, and then to create dedicated virtual workspaces and to organize these workspaces relative to each other such that workflows between tool sets/ work spaces / makes sense, is easy to use, and ultimately makes finding the right tools for the next step dead simple.
But what organizing principle can I identify that can adequately and reasonably segregate my tools into useful piles?
My answer is their functionality.
So my discriminating question is:
What does this tool do, or let me do?
The answer to this question (acknowledgedly at a certain level of generalization) has become my tool taxonomy.
My taxonomy didn't start out this way, though. For many years my initial discriminating question was whether the program was a utility or not. At a second level, I discriminated based on the sensory (UI) modality of the media manipulated by the program; at a third level, I discriminated based on the structure of the data (numerical or textual) it manipulated. (But this created a structure that was very heavily weighted to one branch (the visual and textual, rather than the audible) of the directory structure. In practice, this meant that I worked exclusively in one branch only - so I have in retrospect determined that these were not a adequate 'top-level' discriminants.)
But the folders within my visual-modality branch appeared fairly well distributed by their functions (analytics, design, organization), so when I began organizing my thousands of downloaded application files & DMGs on my Mac, this is roughly where I started.
After a while into these projects, I kind of realized that when I am assessing each application installation file, I could and *should*! reuse the organizational structure I had begun using for my FlowSpaces project. But what a pain to harmonize them all!
Notwithstanding the gruntiness of this work, it just seems to follow that if you know why you have something; or in this case, what you want the program to do, or (especially right after you have downloaded it) if you know the reason that you have taken the time to go out on the internet and find this application, you should be able to file it fairly reliably and easily.
The premise/hypothesis is that if you take the time when the new file lands on your system (in your Downloads folder or whereever) to sort it to the right location (or in the new paradigm, to apply the right tag) based on a 'touchstone' (e.g. easily referenced and manipulable) rubric, then, when you go to install it, adding appropriate Tags and dropping it in the right Stacks/Drawers to enable seamless FlowSpaces retrieval of the new tools will be that much easier. As a bonus: your Downloads folder stays tidy and FlowSpaces does not fall out of usefulness by neglected maintenance...
So both my Downloads folder and my external drive that archives all my old PC programs have the same directory structure now. As does my FlowSpaces Application Drawers folder. And these directory names are also (tightly integrated with or closely related to) the names of the 12 workspaces in FlowSpaces, as you will see...
The organizing principle is simple: Each of the 12 top level directories describes a class of tools by what they do. Inside that folder there is ample room to discriminate further (as required) among the tools in that generic class. The general rule is that further discriminants should all be the same in a given directory; sometimes further types of action, but most typically by asking 'what?' kind of media that the applications act upon.
So the Downloads folder has the following 12 folders in it:

When a new file hits the downloads folder, Hazel opens the Downloads folder and selects the new file. It is then up to the user, who can decide to ignore the window, or to drag & drop the selected file(s) into the right folder. If the user decides to be lazy, that can be it...Or they can 'follow' the file, dragging it into its 'proper' or 'best' subfolder...(This 'following' behavior is most easily accomplished when the default View Options of the Downloads folder is set to 'Column View' with spring folders enabled in Finder Preferences.)
If the user then installs the application from that 'properly filed' folder, I hypothesize the action of explicitly locating the installation file in the given rubric will serve as a reminder for maintaining classification consistency when integrating the new tool into the FlowSpaces by Tagging the application file and adding application shortcuts to the appropriate Application Drawers. (If they install it first thing, right from the Downloads folder, and muck about with the app a bit, then immediately file the application installation file AND the Tag & Drawer the application file, this brief experience interacting with the application might also be useful for maintaining classificational consistency too...But I suspect not if the filing/tagging/sorting step is delayed.)
The integrated terminology of the Downloads 'tool taxonomy' and the FlowSpaces workspace can be seen by comparing the following and previous lists:
  Collect & Tag | Manage | Read & Note | Write
  Converse | Convert | Design | Develop
  Emulate | Analyze | Administer | Display
Ill briefly mention and explain the obvious discrepancies between the two taxonomies, primarily to highlight some classification difficulties and strategies for their resolution.
For 'Collect & Tag,' really there are only a few mechanisms for acquiring new media or data: direct transfer from disks, or network transfer by download thru a web browser, email, ftp or similar application. But for most users, the main application used for collecting stuff is a web browser. In my view, the other potential 'collection' applications (Email, FTP) are primarily 'about' something else. For example: Email clients are basically database-style UIs to email repositories or databases: so one ought to consider them 'manager' applications; though they enable 'reading' and 'editing' of email messages, so a classification problem looms... But this dilemma can be resolved by considering the social context of their use - email clients are really used for communication - so in the FlowSpaces rubric, along with IM applications, email clients are prototypically considered 'conversers.'
This is what I mean by the 'sweet spot' of discrimination... Realizing that, Yes, an average program 'does' many things. But finding the insight to ask, what is it used for?
So the 'Collect & Tag' workspace is cursorily about the web-brower(s) of our choice and primarily about all the tools used to sort, organize, & tag individual files.
This is different from, though closely related to the next workspace, 'Manage', where standalone database-like 'manager' applications stand ready to help you organize whole collections of a given type of media, data, or resource.
For 'Read & Note' workspace, the primary tool category is really 'readers'. This workspace highlights the artifice of some categorization efforts; annotation done during the course of reading sometimes involves writing...which is the name of next workspace. But annotation or note-taking is (or in my view ought to be) in direct & close reference to a source document. So though some writing is involved in note-taking, I consider it a special case of writing that is not easily divorced from the act of reading.
In any case, the 'Write' workspace clears the clutter away to focus on writing.
The applications and programs filed as 'helpers' are all utilities helpful in administering a computer system, disks, and files.