When I first read the post, I thought that maybe Google was reusing sub claims when they shouldn't, but on a closer read, maybe it's the opposite problem - that the sub claim is changing when it should not change?
From the article -
“The sub claim changes in about 0.04% of logins from Log in with Google. For us, that's hundreds of users last week ... Because the sub claim is inconsistent, it cannot be used to uniquely identify users - leaving services reliant on the email and hd claims."
So maybe clients aren't using the sub claim because validating "email matches && sub matches" breaks real users who are not actually changing accounts? AKA, Google is changing Google Account IDs unpredictably? That would be a bug on Google's part IMO.
If those account IDs in the sub claim are changing, at the very least that's a bug in the doc you linked IMO.
I'd have to read the full OIDC spec [0] to see if the sub must remain constant for the same end user, and if clients are required to validate the sub claim before processing a login. If so, and it's changing without the end user's identity changing, that is a bug in Google's implementation and client implementations for anyone using Google as an IDP.
If it's allowed to change, though, and validating sub claim is not required in the spec, maybe clients are correct in not relying on it.
[0] https://openid.net/specs/openid-connect-core-1_0.html#rfc.se...
Edit: from reading the sign in with google overview, it's unclear if they claim to be OIDC compliant: https://developers.google.com/identity/gsi/web/guides/overvi...
it says it's "based on OAuth" rather than "implements OAuth+OIDC" so I guess not being fully spec compliant wouldn't necessarily be a "bug."