I have been wondering whether to go back to Subversion myself. The distributed option really doesn't apply to me, my minimal branching needs are met by Subversion, and oh my god, git's submodules get confusing.
To be clear, in real life, I do not actually like Subversion. I use Mercurial pretty exclusively for my own stuff, and would indeed use some of the centralized Mercurial extensions I linked in the article (e.g., remotefilelog, narrowhg, etc.) to scale upward if I had really big stuff flying around. The article is more about pointing out that going to a DVCS involves trade-offs, acknowledging that we have a lot of tooling designed to fake out those trade-offs, and discourage thinking of DVCS as a strict upgrade rather than an engineering decision with implications and costs and benefits.
Partial repo checkouts, SVN externals are the two areas where I feel I lost something when "upgrading" to Git. So yes, I quite agree, there are definitely tradeoffs.
http://marc.info/?l=git&m=119495815518898&w=2
It works like this: (I just did this test)
#inside of your repo
git remote add vendor $vendor.git
git fetch vendor #grab their code
git merge vendor/master #imports their code into your repo
git mv vendorlib lib #move it where you want
git fetch vendor #grab the next version
git merge vendor/master #git remembers your mv from before
*update
of course since this is git there is yet-another-command called git read-tree to do a lot of this.
It's all described here: http://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging