Whenever the Git vs Mercurial topic comes up I think this thread [1] about Facebook having massive slowdowns with their large codebase using Git is quite interesting.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/18977...
[1]: http://thread.gmane.org/gmane.comp.version-control.git/18977...
This post brings up one of the major issues with DVCS, if you have a large single repo, it just doesn't play well with git/hg. This is even more apparently if you have a lot of binary objects.
Large projects like Android get along swimmingly on git because they have structured themselves such that git is the right tool for the job. If Android insisted on having one single git repo, despite that not being a git best practice, they would have trouble too.
Structure things right and a git based system will scale far beyond what centralized monolithic repos like perforce can handle. If your codebase is growing properly big, splitting your code is something that you'll need to do eventually anyway.
Single git repos get stretched to their limits when companies try to put 10-20 years worth of sourcecode from every single project they ever had (often with large binary files for testing or whatever) into a single repo because they are trying to use it like they used perforce. We're talking anything from several gigabytes up to the unimaginably large.
Is the "best practice" to archive code after a while? Would make some sense, but I'm not sure how that would work. Everyone has to make the switch at once, right?
Git should be able to handle just about any "single project" with ease for the foreseeable future though. If it can't, that is a strong indication that you need to start restructuring your projects into multiple separate "packages" or projects. You can do that slowly over time while you are still on your traditional VCS (just start breaking components out both in source code and in organization responsibility/hierarchy.
After this process is underway, if you are careful and a little clever, you can allow individual packages/projects to migrate themselves to git/Hg. You will probably be in this stage (many people on the old monolithic VCS, many people using git/hg for their projects) for a while. Managing a concept of "packages" at a higher than version control repos is somewhat important here to abstract away exactly which VCS is being used by a particular project (Android's 'repo' is sort of an example of a higher level concept above version control that facilitates Android development).
Ideally you would eventually give everybody using the old system a deadline to migrate to git.
Note that this sort of situation is really only something that large organizations (facebook, or larger) should ever find themselves in. If you're on a small team and you are running into these sort of problems, then you probably have a slightly different sort of problem: perhaps lots of checked in auto-generated code (suggested solution: stop doing that. work on caching in your build system if auto-generation takes too long to do it every time), or maybe too many checked in large binaries (suggested solution: if those files absolutely must be checked in, perhaps look into git-annex).
Edit: here is a slide deck that covers Perforce scaling at Google: http://www.perforce.com/sites/default/files/still-all-one-se... Note the page "Perforce at Google: Main Server". That is the sort of situation that you don't really want to get backed into, but after restructuring your codebase you can construct solutions with git that allow you to scale much further with lower operational cost.
Now, in general I think I agree with your points. Your two specific points I specifically promote at work and on school projects.
And, I fully see how the large organizations you are referring to would hit this. Especially when they essentially have independent projects in development. What I do not understand is where that line is drawn. To the point that I often find myself on the counter argument at work when teams want to immediately start a project in 3 repositories because we may want some utilities used elsewhere.
Take gnome. At face value, it seems like most of the core of gnome could be in one repository. Instead, it is very highly split out and has a specialized build system to support the it. Was this strictly necessary? Or is this more to support other infrastructure ideas at play? (This make sense?)
FB hired quite a few mercurial hacker, they host Mercurial sprints and have a big attendance from FB devs (e.g. London sprint): http://mercurial.selenic.com/wiki/2.6sprint
Facebook is a big user and backer of mercurial. I attended the last mercurial sprint in Facebook's London office (which was great, BTW). Facebook will also host the next mercurial sprint in New York. They have recently hired Matt Mackall, mercurial's creator. Several other mercurial core developers also work for Facebook and are paid to work on improving mercurial as their main job.
I believe at some point they considered both git and mercurial as their new VCS. They have some huge repositories (hundreds of thousands if not millions of commits) and a huge amount of people accessing those repositories. I think they found some scalability issues with git's performance with repos of that scale (http://comments.gmane.org/gmane.comp.version-control.git/189...). Apparently it was easier for them to improve mercurial's performance, perhaps because mercurial is written in python with some performance sensitive parts written in C. Over the last year they have made a lot of progress and mercurial's performance on huge repositories is now even better than it used to be.