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.