The article seems disingenuous. The "huge classes of users" who "remain categorically opposed" to DVCS probably contain a higher than normal percentage of managers.
As for stuff like this: "They need centralization. They need control. They need meaningful path-based authorization. They need simplicity.", all I can say is that the implication that you cannot get control, centralisation, and simplicity in a DVCS, is at least 75% bovine excreta.
Path-based auth is interesting. I realise there are cases (like gaming, as some comments said) where git (etc) may be a bad choice due to huge binaries and the need to do full clones.
But I also think that in a typical corporate environment (which they now claim to be their main target market) this is far more likely to be management failure and a "that's the way we've always done it" attitude than any *real* need.
I am the author of a project called gitolite that does an excellent job of branch-level access control for multiple git repositories on a central server. My target "market" is precisely corporate users of git. So far, I have not seen a situation where **read-access** needs to be restricted to portions of a repo (git can't do that anyway). Write-access does often need to be restricted, and gitolite can let you restrict both by branch name (e.g. only the QA lead can push a commit series into the "QA-done" branch) or by filename (e.g., only the team lead can make changes to the Makefile and files in src/very-important-and-critical-module).
While I may not completely agree with Linus' comment on SVN ("most pointless project ever started", or words to that effect), because it at least taught people what doesn't work, I think continuing on a project that started out as CVS done right is no longer an optimal use of anyone's talent or time.