I'd disagree on this not being awesome, though. 800K -> 143K is huge. You're talking about shaving several seconds off your user-visible load times. You get less cache thrash through having smaller pages. And at Google scale, this could be exabytes worth of bandwidth per month.
I've had code reviews held up while I shaved 3 bytes off the compiled GZipped size, and proposed changes vetoed because they'd add 19K to the GZipped JS size. The entire JS for websearch is something like 13K. Saving 600K+ is absolutely enormous.
This is the sort of statement that SHOULD set off a veritable explosion in your head of "If what he is saying is true, that is awesome. Seventeen exclamation points elided here!", because shaving seconds off user-perceptible load times results in huge, automatic, reproducible impacts to the bottom line, across a wide range of different web sites. You can reproduce it for yourself by A/B testing adding unnecessary delay into your pages versus not adding unnecessary delay, and watching what it does to conversions. Google has done this: they've found that less load time means more searches, which means more money. Amazon has done this: they found that 1 second more means 1% less -- revenue, that is.
Although I don't routinely A/B test bad practices against the default to make a point, I did get a handful of percentage points worth of free conversion back when I first saw one of the YSlow presentations and got religion on this. Seriously -- if you don't already pay attention to page load speed, you have a money tree in your back yard. Go put a basket under it and shake a bit.
If gzipping alone would get the code down to 800kb or something, then the improvement made by closure doesn't seem so awesome.
Nonetheless, it's obviously good to get the file size down to the absolute minimum when you are going to serve millions or billions of copies.