Since the history is preserved in version control, there is absolutely no reason not to remove code you don't need. By the way, this applies as well to commented code within the source: don't comment blocks of code, just remove them; if you'll need them later, version control is your friend.
Later may be even in an hour. The common sense may dictate that if you think you'll need a whole project or a piece of code in an hour, then it's better to keep it or comment it. I would discourage such practice, since reverting removed elements should be a matter of seconds anyway (especially since you remember exactly what was removed). Moving project to archive directory, and then moving it back will take the same amount of time then reverting. As for the commented code, there is a huge risk that you'll end up forgetting to remove it if it appears that you actually don't need it.
Removing entire projects is especially important for persons who join the project. In SVN, for example, the new person has to checkout the last revision to get the source code, which means downloading even archived projects. This can impact the time wasted doing the original checkout, time you can considerably reduce by simply removing the projects you don't need, instead of moving them to a specific directory.
To ensure optimal performance of your team, make sure that:
The version control history will remain forever. I've seen many cases where teams migrate to a different version control and don't bother migrating the history (although it's relatively easy to do). There was also one case where the team decided to remove the old revisions to free some disk space on their server (yes, I know, you find that extremely stupid too).
Message logs are explicit enough and commits are granular enough to be able to quickly find the removed code when needed. Tagging might be used for that (although I'm personally against such usage, including in this particular case).
Developers, especially newcomers, know how to use history and how to get back the removed code properly. The worst case is someone who doesn't know how to do that and will copy-paste code by hand and then commit.
The major problem with that is that version control doesn't know that the code already existed; this decreases the traceability (it's like all this code was written from scratch) and increases the disk usage footprint (since the version control should store the code instead of just referring to an older commit).
