The second type of article is usually written by converts from legacy VC systems (cvs/svn) who have never experienced a DVCS before. They attribute the obvious improvement in usability to Git, never venturing to try anything else; possibly due to the same fundamental lack of curiosity or self-improvement that leads to using CVS/SVN at all (post 2005).
What's more, the migration from a single-branch to multiple-branch model is so empowering that such users tend to view all of Git through rose-tinted glasses forever after. Compared to that experience, relatively minor usability improvements like Bazaar's "every working copy has its own tree" or Mercurial's queues seem insignificant and/or unimportant.
... possibly due to the same fundamental lack of curiosity or self-improvement that leads to using CVS/SVN at all (post 2005).
I (and my successful small business) still use SVN, and have done so since 2007. This choice has nothing to do with "fundamental lack of curiosity or self-improvement." It's a choice born of careful reasoning regarding the suitability of using DVCS in a centralized organization.
I've been toying around with Hg for some time before Git. Indeed, DVCS by itself implies high degree of flexibility and whatnot.
However, I'd still like to single Git out, because of its storage format. In Hg, for every file in your repo, you get one storage file holding revisions -- plus one master file with changelogs. It's just boring files all the way down.
In Git, every object (file, tree of files, commit with a tree of files & parent commit(s)) are represented by hash. The data itself is stored somewhere -- in an interchangeable format (currently two formats are used: blob and pack with index). Storage is somewhat decoupled from toolkit. You can even fix a broken repo by literally copying in file(s) with proper content.
But the true power comes from somewhere else: you can envision defining own data types, beyond files, trees and commits, and plugging them into Git. And having them play along with the usual ones.
A general content-addressable storage :D
(Too bad Venti [1] was invented a bit earlier)
I believe Fossil (the DVCS [2], not the FS [3]) comes pretty close to that, too.
What's more, the migration from a single-branch to multiple-branch model is so empowering that such users tend to view all of Git through rose-tinted glasses forever after. Compared to that experience, relatively minor usability improvements like Bazaar's "every working copy has its own tree" or Mercurial's queues seem insignificant and/or unimportant.