The performance issue mostly comes down to round-trip times and cache hits vs misses. They're making the argument that they're less likely to deliver a delay for a cache miss than your local server or ISP server, a claim that's plausible, but which requires a lot of effort to demonstrate.
My round-trip time to my ISP's local DNS server is about 20ms, and my round-trip time to google's DNS server is about 20ms, so they're obviously using anycasting and distributing lots of servers, so that there's one close by to you. So if they run their DNS servers with more goodlyness than your ISP runs theirs, you may get better performance from the google servers.
Of course, my round-trip time to my local DNS server is about 1/10th of that, but I'll get a cache miss any time I hit up something for the first time, whereas a DNS server shared with lots of other people provides the possibility that somebody else hit up that site an hour ago, and so my query will be a cache hit, saving me a round-trip to a DNS server that's likely to be farther afield. A possibly useful compromise is to set up a local DNS server that's a "caching only" server, one that can respond from its own cache when there's a hit, but forward misses to a remote server, like the google server, a setup that's likely to be quicker for cache hits on their server, but adds a small unnecessary extra delay if they miss.
Their argument is that slow DNS performance is hurting our user experience, and we can perceive that slowness, but we don't properly attribute it to DNS. Personally, I tend to be biased against "outsourcing", and placing my fate in somebody else's hands, and generally against "everything google, all the time". So I'll likely see slower DNS performance every day for the next 3 years, but then revel in smugness on the day the google DNS servers melt down, and for those few hours, I'll have the internet, and its wealth of monkey porn, all to myself.
-harry
