Sometimes I wonder if DevOps isn't really just those who would truly prefer to be developers but don't mind sysadmin work and, for whatever reason, started out doing the latter.
I, too, cringe a little when I hear the term, perhaps because I've always viewed myself as a "pure" sysadmin. That is, this is the kind of work which continues to bring me joy after 2 decades. Application development, on the other hand, despite an ability to code, does not.
CM tools (current and their predecessors like cfengine) as they tend to be implemented strike me as a way of avoiding administering the whole system, by focusing on a single component (servers) and reducing them to a lowest common denominator.
It also fits the pattern of trying to solve problems entirely in a custom software solution, a trait I associate with developers, not sysadmins. This is the source of my inference of DevOps' true leanings.
The reality is that the system consists of considerably more than fungible servers[1]. There's the underlying hardware, the peripheral hardware like disks, database software[2], network hardware and configuration, and service providers.
These are all traditional sysadmin areas, with plenty of room for professional growth and overall benefit. So much so, that I have difficulty imagining why any SA (not a developer in SA's clothing) would wish to do more dev at the expense of increaaed mastery of the infrastructure.
By way of example, something I wrote on LinkedIn, in response to why I'm not a fan of puppet:
I'm uncomfortable with any system that attempts to maintain state in place
on a running system, as well as possibly override the native packaging ethos.
That the client takes its own local file inventory on a fresh system, rather
than trusting the one the package manager has, is wasteful at best. What's
worse, to me, is that it creates yet another system to administer. I haven't yet
found anything similarly suitable for the Ubuntu/Debian world, but I very
much liked Cobbler a couple years ago, as it was primarily a wrapper for
what could otherwise be standard, standalone services (kickstart, package
repo). Even without such a wrapper, yum/rpm or apt/dpkg can do nearly all
the work"
[1] Virtualization and "cloud" notwithstanding, as anyone who's experienced an outage with a hosting provider or an i/o perofrmance issue with a cloud server can attest.
[2] Which can be like an encapsulated OS itself