Ultimately we can't do anything about a server that is near-maliciously determined to be wrong. The hope is we can at least defend against some of the common genuine mistakes at fairly low cost.
The implementer that tries to special-case GREASE values must have first hit an interop problem and thus had a second or third opportunity to think about it. I would hope, at that point, they realize they're meant to ignore unknown ones!
The blog isn't quite right. HTTP/2 requires ECDHE (or DHE, but don't do that) with an AEAD, which means one of the GCMs or CHACHA20_POLY1305 if you have it. It's written as a blacklist, but this was the intent.
What's going on is Chrome and Firefox don't do AES_256_GCM (but Chrome will be adding support in the next release, see [1]), which means it was picking a CBC mode cipher and HTTP/2 wouldn't allow it.
SSL Labs is, in my opinion, wrong about incentivizing AES_256_CBC over AES_128_GCM. The CBC mode ciphers in TLS are composed wrong and very very difficult to implement safely. They'll be gone in TLS 1.3.
SSLLabs capping server scores for just supporting RC4 is kind of silly. The server gets to pick the cipher and the Finished message authenticates the rest of the handshake. So long as the key exchange portion is strong enough (and that's orthogonal to the bulk cipher, although if you're supporting XP, that's probably plain RSA and not ECDHE_RSA), the handshake has downgrade protection. You can securely[1] negotiate GCM with modern browsers while still accepting legacy things for older ones. Just order your ciphers right.
[1] I'm handwaving the version fallback. You'll want to also support FALLBACK_SCSV, which SSLLabs also checks for, until that thing is gone for good.
AES_128_GCM is much much preferable to AES_256_CBC. AES_256_GCM does not have broad support (not supported by Chrome or Firefox) and isn't really worth the performance tradeoff.
This isn't prioritizing quite the right ciphers. The CBC mode construction in TLS has serious problems (MAC-then-encrypt instead of encrypt-then-MAC) and should be considered cryptographically broken. It's incredibly fragile and difficult to implement correctly.
You want to make sure TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is negotiated, at least where browsers support it. (It's spelled "ECDHE-RSA-AES128-GCM-SHA256" in OpenSSL.) There's a small handful of others that are also acceptable, but between ECDSA certificates being rare and CHACHA20_POLY1305 still being standardized, that's the one you want. All the rest are legacy baggage.
It's been fixed, but that was a bug in Chrome's NSS glue between NSS and the OS X native key store. (The fix is under third_party/nss, but no one else carries that particular file.) As far as I know, it works fine on other platforms and in NSS itself.
The implementer that tries to special-case GREASE values must have first hit an interop problem and thus had a second or third opportunity to think about it. I would hope, at that point, they realize they're meant to ignore unknown ones!