But does this fixes some real issues (if so, than what are they?) or just fixes the excessive connections to zookeeper?

Yes, it is fixing a pile of issues.

Without forcefully invalidating ZooKeeper session before establishing a new one, there was a possibility that server is using two ZooKeeper sessions simultaneously in different parts of code. This is stong antipattern and we are aware of it and always prevented it until it was broken in #14678.

ZooKeeper is linearizeable for writes, but not linearizeable for reads, it only maintains "sequential consistency": in every session you observe all events in order but possibly with some delay. If you perform write in one session, then notify different part of code and it will do read in another session, that read may not see the already performed write.

Every ReplicatedMergeTree table is using only one ZooKeeper session. But if several ReplicatedMergeTree tables are using different ZooKeeper sessions, some queries like ATTACH PARTITION FROM may have strange effects (but it's unclear to me if real issues existed).

Also the code was incorrectly comparing if configuration is changed. It was comparing configurations after shuffle of hosts was done. So, almost everytime configuration is considered different and a new ZooKeeper session was established.