There are two good reasons to checkout only a subset of the repository:
1) Large binary or data files -- For this, there are various solutions of varying hackiness.
2) Your project has grown into several sub-projects -- The best solution here is to clone the repository to new names and then refactor and trim the respective project trees with a lot of deleting. You'll thank yourself later for improving your architecture and there will no longer be a partial check-out problem.
The real issue for both of these, is handling unversioned or independently versioned bits with respect to all the other bits. You might want some unversioned binary blobs, but you might also want some versioned giant csv files without having to download all the old versions all the time. Source code has one versioning strategy, data files another, photoshop files yet another. No version control system today really lets you pick which versioning strategy to use for which files. And none of the existing "sub-module" type extensions are really great either.
Actually, the worst problem with submodules in modern DVCSs is handling dependencies. If project A depends on project B and project B and the API exposed by project B varies over time it is pretty easy to keep both in sync and working. Except, when someone needs to check out an older version of A they need to figure out which version of B to check out (and it might not be as easy as checking out the latest B in the date that that version of A was committed). Git allows you to mark a specific revision of a submodule, but then updating the whole project is no longer a single command, and there are some problems with not pushing everything at the same time.
3) You have a small patch and want to update it to the HEAD version before submitting. You worked with the source you obtained in some other way (from a source package for example). Now you have to wait 10+ minutes on a large project, downloading all the changes since 1970, just to change the newest version of a single file.
4) The project has grown into several sub-projects - but you don't control that repository.
"shallow repository
A shallow repository has an incomplete history some of whose commits have parents cauterized away (in other words, git is told to pretend that these commits do not have the parents, even though they are recorded in the commit object). This is sometimes useful when you are interested only in the recent history of a project even though the real history recorded in the upstream is much larger. A shallow repository is created by giving the —depth option to git-clone(1), and its history can be later deepened with git-fetch(1)."
There are still issues; you can't commit for instance, but you can update to HEAD to update your patch, with a depth of 1 you only get the most recent changes.
I agree this is a definite weakness compared to svn, but the problem is that svn gains this facility by having no concept of a project. Let me repeat that: in svn it is technically impossible to identify the project tree.
The problem with that, of course, is that merging only makes sense if you are merging branches that occur at the same tree-level in a project. This is why subversion merge tracking is so buggy and half-baked... because any given directory could be a project tree, a subtree, a branch, or a tag, and you could merge any of them. Sure if stick to certain conventions it works pretty well, but technically the whole implementation is a minefield, which is why svn will never be as robust as other systems that don't make this mistake.
Even though git's submodules and subtrees leave a lot to be desired, and have significant room for improvement, they will never be as convenient for partial checkouts, because the requirements for svn-style partial checkouts require crippling the entire system.
