DNSBench does not tell the whole story due to use of RRL or response-rate-limiting, which is a common feature in BIND DNS servers that most techs simply don't know anything about. Most DNS servers should be using this feature to varying degrees, which has a huge impact, negatively or positively, by its configuration. In fact, the configuration of the DNS server alone is the most important factor impacting the performance of a public recursive DNS resolver. You could use DNSBench, which is great software for determining a fast record response and latency of a server from the public side, but the real-world behaviour will vary once you give it a real load from a network, and this is due to the default and custom configured server in relation to total inbound recursive requests plus caching policy of that server. A lot of applications make many unneeded and identical hostname requests and distribute that load across multiple UDP ports, which I believe DNSBench does not account for, but the server would begin to block in many cases where the DNSBench application would only detect that as a latency spike or delayed response, but in reality the server could be dropping the request without a response.
In relation to preventing malware, DNS is the most resource-friendly way to eliminate known malware threats that I've ever come across other than at a security-enabled firewall. AV is only effective if each endpoint is up-to-date and if the AV provider uses blacklists that are up-to-date as well. This means each endpoint has to be managed against the blacklist independently or from the central AV management server. Using the AV method to redirect only mitigates threats at the endpoint which needs to be done x amount of times over and over, where x is the amount of computers that need to connect to the internet. Even if the DNS responds quickly, the endpoint would slow the perceived speed of the internet to the user.
You are correct about the proximity argument. That is true. You can use DNSBench to help isolate the close servers vs the farther ones.
Regarding your second paragraph where you prefaced with "If I were really concerned about privacy". I'm confused because I thought that privacy was your initial concern, which spawned my initial response. I was trying to debunk that notion of privacy that I used to believe myself until I started to run my own public server to see the logs myself.
Regarding Google being able to snoop your data across multiple devices and what not...I am not sure if I mentioned Google apart from their DNS services...not sure if this even comes into play. Regarding their market dominance, though, I'm with you...They are too big and/or I share similar sentiments.
Regarding OpenDNS...they are no different than Google. They collect data. Regarding OpenDNS's performance...I have mixed experiences deploying their DNS in years past depending on the ISP deployed on location. They are a great choice as well, especially if you pay for additional features.