Hmm, OK -- I see what you mean. I think that Google's suggestion is debatable -- I don't personally agree with it, but I can see the argument they're making and it's not an unreasonable one.
Basically, the setup you have right now is that when a browser fetches a static page for your site, the response will have a "last-modified" time, which our server will have taken from the file timestamp. The file's content and that last-modified time will be put into the cache. When a browser requests the same URL again, it will send a "don't bother if it hasn't been modified since time X", where X is of course the cached last-modified time. If the file has not been modified, our server will respond with a short "nope, it's unchanged" response, so not much data will be transmitted -- it will be a quick response to the browser. If the file has been modified, it will send back the new file contents plus a new "last modified" timestamp, so it will be slower, but that doesn't matter because the browser really needs the new data.
This means that static files are pretty quick -- they're only sent in full if they have been changed. But it does mean that there's always a request for each file, and even a short "not changed" response requires a browser-to-server round-trip.
What they're recommending is an "expiration date" header. This can be helpful, but it can also cause problems. When you send a header like that, the browser is allowed to continue using its cached version and not even check with the server to see if it has changed. So if your static files don't change often, things can be quite a lot faster -- it skips the "has this file changed?" round-trip until the file expires from the cache. However, if they do change from time to time, it can mean that people browsing your site wind up using the cached version -- so, for example, if you change your main (uncached) page to look different, and as part of that update the CSS, you can wind up in a situation where people are seeing the new content with the old CSS, and it all renders weirdly.
You can work around that by changing your CSS filename every time you update it, and there are tools to help automate this (eg. by automatically using a hash of the file contents of the file contents as its filename), but it can get complicated quite quickly.
Our setup right now is designed to go for the former, "always get the browser to check" system because it's generally (in our opinion) the best way to do things, especially if you're actively developing the site. But perhaps we need to add something to allow people with sites that don't change that often, or who are willing to change filenames for static files in one way or another to force the second model.