If you connect to https://google.com (without www.) you get a HTTP 301 redirect to https://www.google.com/ . Then if you connect to https://www.google.com/ the response includes the strict-transport-security header.
I contend this is a (small) security gap, because the strict-transport-security attribute never gets set for the top-level hostname, google.com. This means that no matter how many times the user has connected to google.com or www.google.com, if an attacker manages to send them to http://google.com/ , and the attacker is a man-in-the-middle who can redirect google.com to a site the attacker controls, they can eavesdrop on the connection. (Also, Google's entry on the HSTS preload list only applies to www.google.com, not google.com.)
However, Google is rejecting all reports of "security holes" regarding HSTS: https://sites.google.com/site/bughunteruniversity/nonvuln/lack-of-hsts with the statement "Migrating all the domains to HTTPS, and deprecating all clients that can only talk over plaintext HTTP takes time."
I contend these objections makes no sense. If a client only speaks http, then the way to continue supporting that client is to continue serving http. But if you serve the STS header over https connections, you're telling the client, "Hey client, since you obviously speak https, this host promises it will always serve you https in the future and you should always make https requests to me." The only valid reason not to serve the STS header would be if you think the hostname might some day not support https any more, which is hopefully not the case for google.com!
Perhaps there are subdomains of google.com that don't support https. But then google.com can just serve the STS header without the "includeSubDomains" attribute, so it won't be applied to subdomains.
So I maintain that: 1) Not serving the STS header for the hostname google.com is a security gap. While it's a small gap, there is no offsetting legitimate reason not to serve the header. 2) It is not a valid objection that they "want to keep supporting clients that only talk over plaintext HTTP". 3) It is not a valid objection that they have not migrated other subdomains to https yet.
Am I missing something?