Pre 3.5.0 zookeeper reconfiguration of a running cluster was also much harder - that was a significant discussion point on Kubernetes when we had the etcd vs (anything) discussions early after open sourcing.
I still think etcd total ordering over history also made reasoning about changes in the system while we were writing the first versions of the controllers and caches and list-watch loops. ZK had partial order, and I was leery of that at the time.
- No TLS security story
- An abandoned RPC/serialization system that was hard to use in other languages
- A consensus algorithm that differed from systems described in literature
- A large RAM footprint
Awhile ago some etcd engineers made an experiment in fact to try and run ZK client protocol on etcd with a proxy:
https://github.com/etcd-io/zetcd https://coreos.com/blog/introducing-zetcd
Today, etcd performs much better than ZK and I believe it is much more widely deployed with a wider set of engaged users.
https://coreos.com/blog/performance-of-etcd.html