The reality is that etcd is still probably a year or 2 away from being production ready.
In the mean time Zookeeper has shipped dynamic ensemble configuration which bring parity to the only thing etcd had any advantage in. (Not that it -really- mattered, most people that were running dynamic ensembles were already using Netflix's Exhibitor)
Zookeeper is also faster, has more features and you need it anyway if you are running SolrCloud, Mesos, Hadoop etc.
Zookeeper definitely has some advantages both in terms of maturity and features.
I'm not sure though that Zookeeper is universally faster than etcd (certainly as you add nodes it slows down... though most people don't need more than 3 or 5 nodes).
Dynamic ensemble configuration is definitely a place where Zookeeper was lacking before, but it isn't the only difference that matters. The big difference I remember with etcd was partition tolerance. Last I checked Zookeeper was all on the consistency side and it's partition tolerance basically just wrote off the smaller partition. Either choice can be a good thing or a bad thing for a directory/orchestration store, but particularly as you scale up to large numbers, partition tolerance semantics seem to better match the use cases.
So I don't think etcd is all inferior to Zookeeper, and I understand the desire to build a system where all components are fundamentally AP, but sometimes having a bit of impurity and some duct tape hackery in your model can help you get out the door faster and focus on more significant technical challenges that will help you build your community. Once you have a community, you have more resources to address that duct tape.
In the mean time Zookeeper has shipped dynamic ensemble configuration which bring parity to the only thing etcd had any advantage in. (Not that it -really- mattered, most people that were running dynamic ensembles were already using Netflix's Exhibitor)
Zookeeper is also faster, has more features and you need it anyway if you are running SolrCloud, Mesos, Hadoop etc.