Orchestration has come up at the Chef design summit both years and it's a fairly overloaded term so I can understand your desire for something more succinct. When building a service that is distributed over many nodes certain challenges manifest like dependencies and ordering not of recipes on a single node, but where you need node A to converge with recipe B before node C can converge with recipe D. You can do this in Chef, it is simply more elegant in Juju because of it's tight integration with a distributed lock manager (zookeeper) [1]. There's several different ways that people handle it in chef w/o a distributed lock manager:
1. Skipping parts of a recipe, expecting node attributes or databags to be manipulated by a recipe(s) on other nodes to achieve a state requirement in a future convergence
2. Failing a recipe, expecting node attributes or databags to be manipulated by a recipe(s) on other nodes to achieve a state requirement in a future convergence
3. Polling with timeout in a recipe, expecting node attributes or databags to be manipulated by a recipe(s) on other nodes to achieve a state requirement during the current convergence window
That said, chef combined with a distributed lock manager allows for more elegant solutions involving the "watch" primitive. I've been seriously tinkering with the idea of setting up zookeeper, placing metadata that could benefit from a watch in znodes and having a ZK [3] daemon that responds to watches by signaling the chef-client deamon or runs chef-solo.
I'm by no means a Juju expert so perhaps this is something that could easily be done by utilizing Juju alongside Chef. I wouldn't feel comfortable doing this though because Juju is clearly more than a just lock manager and I'm not a fan of using two tools with overlapping domain to add a single primitive than can be satisfied with a simpler tool.
Doozer is another lock manager that appears to be able to satisfy watches, it and Zookeeper are influenced by the paper Google published on their Chubby lock service [4]