Me too! I call it "shell scripts". Been in production use since ~1970. Seems to handle most of my needs. I just wish it was written in JavaScript.
Obviously this limits you to unix first up, a fairly serious limitation.
Second, it's full hard to catch, security-related bugs, particularly if you attempt to make it portable across disparate unices.
Third, its significant and inexplicit dependencies to achieve pretty much anything (downloading and unpacking files, diffs, accurate snapshots, nontrivial analysis, whatever) remain technical debt and a pain in the ass both in the sense of achieving basic functionality and long term stability.
Finally, because the rest of the world has moved on from shell scripts for all nontrivial tasks for well known reasons (right tool for the job), you will find hiring anyone to manage that really hard.
However, yes, they have their place and your point is valid. For unix-like platforms cims goes one level higher than shell scripts and demands an executable that returns an appropriate exit value and emits issues to stderr when executed on the specific build platform, which may be a group of OSs ('unix'), a specific distro ('arch'), a specific version of a specific distro ('gentoo-my2015febbuild') or even a specific version of a specific distro with a specific config. You could therefore write in any language available within the environment, with the appropriate portability penalty. The environments are defined by: you guessed it, executable tests in the same spirit. This means that being as specific as required or felt appropriate ("optimistic portability" with shell scripts, for example) is allowed, while being completely repeatable once a functional platform version and service build process match is achieved (for services targeting inexplicit platforms like 'unix'). Capiche?
Now the much harder problem of orchestration is still an unsolved problem and I think that is what the author was referring to.
For the devops crowd, I think fail-closed or fail-safe shell scripts work really well for orchestration. Too many times i've seen a really complex chain of operations make it much harder to debug and fix a problem because the tool was trying to be smarter than it needed to be, or ignored failures. You get faster development time, simplicity, portability, extensibility, interoperability, etc for free. And really i'm sick of re-writing the same tool only to later fix it with a shell script because tackling the tool would be too complex or time-consuming.
I nearly choked. Perhaps in the 1980s when you could hire people with shell minutiae memorized, this was a good strategy. These days, I would be wrapping the executable for the job (purposefully in an unspecified language to facilitate broader use and survivability of the design) in a layer that makes its environment temporary and OS-level sandboxed (to stave off security challenges), and completely explicit (to nip the clasically vast number of undocumented dependencies in the bud). Ideally, versioning of such environments and their builds would be supported. That's exactly cims.
The second point is correct; it's deterministic in the sense that the ordering is always the same, and as much as Dockerfile are (they're also regularly described as deterministic). I should probably clarify that somewhere.