if you want to interact with chef via command line, knife is your best bet,
knife has nothing to do with orchestration, its a chef aware , mixlib-cli based component (which means its primary goal is to build command line tools), which also provides following additional features:
1) re-usability with other knife components. For example you can build a knife server provision -C cloud , and use knife-linode, knife-google or knife-ec2 based on the -C parameter
2) it has a ui component which can do colored output, and provides a presenter. For example inside knife if you do ui.outpur(object) it will automatically print readable colored output by default, but can also print json if you supply -Fj
3) Chef awareness.. it has a baked in rest method (with and without auth), helpers for doing crud operations on chef's domain objects (like apiclient, node, role etc).
that said, knife has some pain (primarily propagating from mixlib-cli), but their workarounds are pretty well documented.
As per your first argument on orchestration, first of all each organization has their own requirement of orchestration, with varying level of complexity, and if they can be offloaded to command line mechanisms, i dont see any pain in building knife plugins and using them for orchestration. For example, if you decide to remove a node from a load balancer, do a deployment and add it back again, and you want to trigger it from jenkins, you can pretty much do this with knife plugins, and trigger them from jenkins.
What we should be concerned about, is not to build thick plugins, or putting way to much logic in them. If you can refactor them into separate classes you get the ability to reuse them across knife and other components. But this is true with any library from re-usability standpoint. For example most of the knife-cloud plugins uses fog underneath and are pretty thin.
on the contrary i'll not try to go ployglot unless i have to. Re-usability will be restricted to individual components once you go ployglot. Also you have to maintain the language/framework specific idioms & toolchain. This is fine if you have people who are good at multiple languages, but often times its not the case. If i can use Boto then why not take the func/fabric/salt route (which has a 0mq based orchestration built, and you can fall back to ssh also because you have func/fabric ). They are pretty decent, and also i get to reuse my code across these components. I would only recommend going polyglot if the underlying tool or framework forces me to do so. Like we built our jenkins - chef integration in java, because jenkins java binding are first class.
At the end of the day I want to come of with a solution that comprises of smallest , readable, testable code, that can be extended intuitively
comments ?