We have noticed exactly the same problem with one of our customers. And he could easily reproduce it in a lab with recommended ESET setup.
One observation is that all update calls to hxxp://update.eset.com/ are redirected by that server to umXX.eset.com servers. So the files are downloaded from those umXX servers. But identical .nup files on those servers are not seen as identical by the proxy. Meaning the cache for a .nup file is only hit if-and-only-if it comes from the same umXX server.
So, if you have for example 10 clients asking updates, via the proxy, to hxxp://update.eset.com/, then in practice only a fraction is hitting the cache due to the round-robin redirect policy from hxxp://update.eset.com/.
I hope you are able to reproduce and fix this asap because, well, ... our customer uses satellite connections, so it hurts ... a lot.