Saying JQuery's expiry time is 1 year in the future means that Google is telling browsers who get the JQuery script "Hey guys, you can rely on this being constant for a year, after that you'll probably want to ask for a new version." The poster above you apparently thinks this is suboptimal, because a user should be able to cache a particular version of JQuery for longer than one year. I think that it is irrelevant, since in actual practice almost no user agent will reliably persist a cache for a year, and 1 extra HTTP request a year isn't enough to worry about, anyway.
(It is also a whole lot of black magic compared to front-end optimization. See any of the presentations by the YSlow guys -- google [high performance web sites] and look for the slides or videos. They give simple, tested, repeatable "do this and it will work" best practices. Backend optimization, on the other hand, relies far too much on handwavy lore and near-useless-or-actually-harmful micro-optimizations. For example, "StringBuffers are sooooooo much faster than String concatenation!")
I second that. My experience is first look into the DB time and second browser rendering. I have thought Python was the cause for slowness many times and each time it again proved to be DB time. Also, don't run multiple selects to the database for a set of records, make it one select.
I've also found Yahoo UI and performance section a great resource too. For better or worse, Yahoo! apps tend to be heavier on the design and graphics side so they have some good practices in place.