The point is it doesn't save overall bandwidth used, it saves bandwidth on shared/contended resources. If you have, eg a switch with 10 1Gb ports[1], and 1 1Gb uplink, and 4 of those are doing something intensive enough to saturate that uplink, someone who requests say, a full download of the gmail client, then it could go strictly across the switch to one of the other 6 local google boxes that has a cache of that, and at a lower latency and impact on other people than going to through the uplink to the nearest cache.

Now, this could also be done in the switch closet, you are right. However, since this would have to also go through either the uplink, or every switch would need a port dedicated to a cache network/box, it would start getting expensive at switching points. Each would start looking like a mini-data (micro? nano?) center. At that point, you could just eat that cost, or say "what are alternatives that cost the same or less in capex and opex?" Perhaps with Google's network-fu, they have solved similar problems in data centers already, and said "we can use our caching/routing stuff here, and put a small capex increase each customer box, which we also need no matter what, and decrease switching point capex, and since it is a simpler network, reduce opex too".

Essentially, it is a similar problem to the one bittorrent solves, just at a different scale/locality. It also starts to look like solutions some vendors/ISPs looked into at one point for bittorrent - instead of stopping bittorrent, keep a map of local people seeing segments and reroute requests for those segments to the local network rather than across the uplink.

[1] assume a decent switch with a full mesh backplane. Also assume real switches will be used with real numbers, not my exemplary ones - the analysis will be the same, but the numbers will of course be different.