It's too long to deal with point-by-point, but I can do a few:
* It's not odd that a cert for * .google.com would be served for google.fr. Check the SANs.
* Google does not use EV certificates.
* Google's frontends have many IP addresses. Seeing differences at different times and places is normal.
* Our leaf certificates really are issued for only a few months.
* We will be off SHA-1 by the end of the year but, at the time the article was written, one certainly could have received a SHA-1 signed certificate from us.
* http://clients1.google.com/ocsp is our OCSP responder and, yes, you'll get 404 unless you send a correct OCSP request with a Host header.
From what I understand:
TL;DR: CDNs often have certificates that are valid for a lot of domain names. Getting a valid certificate for any of these would allow you -- or an intelligence agency -- to hijack the https connection via MITM, and in this case, serve an altered binary (e.g. malware) instead of the real Google Chrome browser.
 More info: http://security.stackexchange.com/q/23042/10863
1. The author gets confused by the fact that the SSL certificate used by Google uses the SAN (Subject Alternate Name) extension to allow it to be valid for multiple domain names.
2. The author expects Google's web site to have an EV certificate, which it does not, and assumes that this is a sign of malicious activity.
3. The author misinterprets some run-of-the-mill CSS warnings as malicious activity.
4. The author misinterprets SSL Labs' lack of an EV certificate as meaning that SSL is not operating on their site at all. (Even though it looks exactly the same in the browser as the Google site they saw earlier.)
5. The author gets confused by Google's use of multiple IP addresses.
6. The author is surprised that anybody can point a DNS record to a Google IP address, and gets confused by the fact that one particular indexing site (Robtex) lists some of these records first.
7. The author sees something unusual about the DNS for Google Tag Manager (http://www.google.com/tagmanager), but doesn't give enough details for us to figure out what it is.
8. The author is surprised that Google is still using SHA1 for a short-term certificate. (To be fair, I'm a little surprised by that too, but I'm sure they have their reasons.)
9. The author expects an OCSP responder endpoint to be viewable in a web browser, and is perturbed when it is not.
10. The author is surprised that not all of Google's short-term certificates are described online, and that there are a lot of them.
11. The author is surprised that Google has a variety of different IP addresses and SSL certificates, and that their visibility may change.
12. The author imagines this all to be part of some vast conspiracy.
13. The author examines the perfectly good Chrome package s/he downloaded, and is confused by its use of the standard "netscape-remote" protocol.
14. The author draws some parallels with a completely unrelated Gmail outage, and draws the whole thing to some strange sort of conclusion.
About all I can conclude is to stay far away from their VPN service. If they can get this confused by a perfectly normal situation, I'd hate to see them trying to investigate a real security threat.
As for the routing: you have seen BGP issues crop up, right? I think Turkey took Youtube offline for a while, when they intended only to block it within their borders. I wish it took the resources of an intelligence agency to screw up routes.
Seeing a multi-domain cert from Google is kind of strange. They certainly don't need to share IP addresses or certs.
Firefox has two pre-installed certs for "Google Internet Authority G2", one of which is still valid, and the other (serial 02:3A:69) has expired. The expired one may have been compromised, allowing the creation of sites which can impersonate Google sites. It's hard to tell from that article, though.