At Google, there's a culture that if something is broken, call it out so that it can be fixed. At best, you will save thousands of employees hundreds of hours. At worst, you'll learn why it's broken. Many problems are inherent in running a large company, and there is no easy fix for them. But many others have simple solutions that make everyone's lives better.
The way I see it (and this is completely my personal opinion here, not speaking for Google), he and other Xooglers who've written posts like this are being Googley. You don't work for seven years at a company without absorbing some of the culture, and that culture doesn't simply leave when you hand in your badge. Posts like this are not all that different from something you would see on internal Buzz or mailing lists, and I think the spirit of them is not to "bash" Google, but to call out things that Google could improve upon even after the Xoogler has left.
Or maybe not. Oftentimes, things don't even need to bubble up to the top to have an impact. You've got a very distorted picture of large organizations if you think that Larry suddenly makes a decision and then the whole company immediately does what he says. Large companies are really collections of small independent groups, and nobody really understands everything that's going on, and often times the worst problems are best addressed at the middle-management level. I think most rank-and-file Google employees have the same goals as Larry Page: we want to launch things quickly, we want people to use our stuff, we want to have a big impact on the world, and we want the share price to increase. The problem is translating that big-picture desire into specific practices and processes that'll result in that.
Ever watch a friend slowly slip away? They change from something you knew to something unrecognizable. You have to at least try to do something about it.
The introduction - and then pervasiveness - of unit tests was one such change that basically took over Google culture despite the ambivalence of the founders. People found they could simply move faster when they had confidence in their code, they started sharing the knowledge of how to write better tests, and eventually it simply became the accepted thing to do. (Interestingly, the testing intergrouplet failed several times before they struck on a bottom-up approached that worked. As with everything, persistence is important inside big companies too.)