postgres bloom index
When bloom was introduced in 9.6, parallel query had just been introduced and is was turned off by default.  Bloom appeared to be better than a non-parallel sequential scan in the example given.  But when you can do a parallel seq scan, it appears better than using a bloom index does.  It is not actually better as can be verified by turning off parallel query with set  max_parallel_workers_per_gather TO 0 and looking at the actual executions speeds, but the planner thinks the parallel seq scan will be better.  It looks like maybe the cost estimation part of bloom could use some work.

The example code was not updated for when parallel query was turned on by default, in v10, so it no longer works as advertised.

Note that your example never achieved any index usage at all, so you can't really draw any conclusions about which index is better for that scenario.