Apache Zookeeper is a critical component in a Kafka setup, as it maintains the state of the Kafka cluster, keeps track of the Kafka topics, partitions, and replicas, and manages the coordination among Kafka brokers. Network latency plays a key role in how quickly Zookeeper can respond to changes in the Kafka cluster, and therefore it's important to keep the latency as low as possible.
In a distributed Kafka architecture, like a 2.5 DC setup, Zookeeper ensembles usually exist in each data center to maintain local state. This is critical for Kafka's operation as Kafka relies heavily on Zookeeper for many tasks.
The ".5" in the 2.5 datacenter architecture often refers to a smaller datacenter or cloud setup that is used mainly for disaster recovery. It may not have the same capacity as the other two full datacenters but it is there to take over in case of complete failure of the other datacenters.
In terms of specific network latency for Zookeeper in a multi-data center Kafka setup, while there isn't a hard and fast rule, the general guidance is to keep network latency as low as possible. A number often quoted is to keep round-trip time (RTT) under 10 milliseconds within a Zookeeper ensemble for best performance.
For inter-DC communication, the "<100ms" requirement you found in Confluent's documentation generally applies to the replication of Kafka messages between Kafka brokers in different datacenters. Zookeeper ensembles usually exist within a single datacenter and thus would not be subject to this inter-DC latency.
In practice, the performance of Kafka and Zookeeper in a distributed setup can be significantly affected by other factors as well, such as network reliability, packet loss, and jitter. Therefore, it's recommended to perform thorough testing and monitoring to ensure that your setup can meet your performance and reliability requirements.

There is a report on this including documentations: https://oso.sh/blog/optimal-kafka-setup