If 1 out of 1024 false positive is the target, then using 8 bytes per entry should be more than enough, which gives ~3MB of data without any magic.
The article is a bit untidy, so it would be nice to get a clearer picture of the sizes of the different approaches.
But the point was that you can beat a Bloom filter on size, for the same performance, if you use only a single hash function (making the Bloom huge) and then compress the result.
Of course, you lose the random access in that case and, if you're looking at processing the whole thing for a lookup, then the volume of the uncompressed data becomes a concern. Thus the GCS...
Which values are you using for the matching? I was assuming a fingerprint of the cert. Have you considered compressing the domains? Compiling them to a DFA should yield a very small structure, and you then will need far fewer bits for the actual fingerprint.
But that's the uncompressed filter. It compresses way, way down: to about 8 bits per entry. That gives 400KB of data, still with a 1/1024 false-positive rate. Much better than 3MB.
If you consider (uncompressed) Bloom filters with arbitrarily many hashes, the best you can do for a false-positive rate of 1/1024 is about 14 bits per entry.