I’ll have to read the paper again, but if I remember correctly for that technique you need to have control over (or at least detailed knowledge of) the wall clocks at each node. You then construct a event window that is equal-or-greater-than the amount of drift between the wall clocks. You only commit events at the end of each window. This is great if you’re doing distributed systems for Google’s data centres.
The Bloom Clock has the disadvantage of being probabilistic, but the advantage that you stay fully in logical-clock land with an unbounded* number of participants with unknown wall clock drift. It depends on the events (rather than participants) much like how IPFS depends on the data not the location.
*Practically unbounded, depending on the size of the bloom. There are options for increasing the size after the fact, but could possibly break for people now aware of the increase (but maybe not… would have to look at it more closely).