My $0.02:
I've done a lot of work using this style guide religiously, largely because it was what my team came together over. It was also the most cogent guide we could find online that was more than merely prescriptive. It's exactness was the overall deciding factor.
I hated using it at first. Overall, the guide is very regressive, and chops the legs off of C++ such that it's not much more than "C with namespaces and classes." You could even go as far as to say that most arguments in the guide reduce to "this isn't a problem in Java or Python because you can't make this mistake, so don't use feature X here at all." Ultimately, it keeps you from doing anything that would allow bugs to creep in by mistake or by misinterpretation, by keeping it all nice and simple. And this is where this style guide actually helps.
The problem is that C++ provides almost too much leverage. Left unchecked, developers will likely use the language to its limits, which inevitably will confound other members of the team. While the program may be a masterpiece of template code, move semantics, and other concepts, it's now unmaintainable by anyone but the original author. Business wise, it's vastly preferable to have an uninspired piece of software if it means you can fix bugs while half your staff has the flu.
Also, consider that the goals of the Google C++ style guide align incredibly well with Go. To me, this is a very salient case against using C++ if that guide is at all a good fit for new development. Go has a very tight language spec, and a (IMO) superior concurrency model that is easier to construct, reason about, and debug. And it's still a compiled language.
Anyway, I'm proud to say that I have delivered excellent results, and relatively bug free code using this guide. If left to my own devices I probably would have used too much template magic and other mechanics that, while are all valid C++, would be harder to debug and understand by other members of my team. The resulting codebase is boring as all hell to read, but stable, reliable, and works incredibly well.
The downside is that compared to conventional languages, the result still takes a long time to compile, is twice as much code as is needed (header files), and relies heavily on smart pointers to manage memory (may as well use a GC). Again, this is why I mentioned using Go earlier.
One last thing: this guide does not stress the importance of "const correctness" in class construction. Add that to your work and you'll really have some solid code to rely upon.
tl;dr: For new development, either forgo this guide completely, or just use Go. Otherwise, you'll just piss off experienced C++ developers by using this thing.
Edit: I forgot to mention that the GSG has a massive blind spot for exception safety. Just because your code doesn't use exceptions, doesn't mean that the libraries you use don't throw. This includes the STL; the guide should steer you away from throwing variants of STL functions/methods, but it doesn't. So be on the lookout for coders not throwing try/catch around third party code, and refusing to use basic RAII (also not mentioned in the guide) to make things airtight. Either that, or just except that every exception-based runtime fault should halt the program, and that it's an acceptable failure mode (probably not).
