That implicit vs explicit ordering becomes very important in bigger teams (or even when sharing deployment between multiple teams). Everything is fine when you're writing your bit - it works as you wanted. But then someone else takes over, or bugfixes something - and they can do one of two mistakes: silly one - assume some dependency where there is none and write some more-complicated-than-necessary workaround; or a very critical one - fail to spot a dependency and assume they can reorder some steps, or split them into separate modules.

I've seen this a lot of times when working with chef already. Someone moves a very trivial thing to a different place, or adds/moves a notification - current system works, clean deployment works, ... but current system will fail on the next reboot or package update that cascades in an unpredictable series of events. Unless you explicitly list all existing dependencies, the system is very fragile and sensitive to modifications. I agree that most people deploying a single-server webapp will never run into this, notice the problem, or even care about it. When deploying a multi-host, minimal-downtime infrastructure it becomes a problem though.

I can appreciate the simple chef/ansible way of provisioning things, but starting with some size I think that explicit dependencies are the only way to go. Puppet/salt allow me to do things that are quite hard to do in chef.