The largest time expenditure is on the loading from an external server, not the processing once it is local. Don't think the author understands this.
in most cases, js performance is a non issue, but when it is, it's interesting to see how and where you can optimize, which is really what his add-on (again, obliquely the real point of the post) seems to target.
"From these preliminary results, I believe that most sites that use jQuery could considerably reduce the amount of JavaScript that they serve by using Closure. As always, compiling custom JavaScript for every page must be weighed against caching benefits, though I suspect that the Compiler could find a healthy subset of jQuery that is universal to all pages on a particular site."
This is the interesting point - is there a subset of jQuery that includes enough for most sites? That subset could potentially be served alongside the main jQuery release, and if enough sites use it, it might be worth it.
Otherwise, right now, caching means jQuery bloat isn't too big a problem, I believe.
Honestly though, I've never done anything at large enough scale that serving something like 14kb instead of 29kb mattered to me or my users.
The main point of the article still stands though. Closure and similar tools make a lot of sense because they can reduce the size of js quite a bit. Especially for huge apps that require several libraries but only use parts of them it can make a huge difference.