One example the paper gives is auditing an election by looking at a random sample of polling sites. Before the election, the government commits to using a specified algorithm to select polling sites to audit, with the random input coming from the first beacon value on the day after the election. This verifies prior to the election that the auditing will be random without revealing what polling sites will be audited (in fact there is no way for anyone to know that prior to the beacon value being published). The government can also use multiple independent beacons. Assuming not all the parties are colluding, this does a pretty good job demonstrating the auditing is random.
1. Each party shares an encrypted string whose plaintext starts with, "I'm being honest about my key."
2. The parties share their keys and decrypt everyone else's strings.
3. The strings are concatenated and hashed to produce a number that no party can bias.
This is a formalization of rock-paper-scissors, a protocol for generating fair random numbers that we may have used as kids.
An interesting property here is that with the old NIST beacon version, the beacon operator could actually change the result assuming the other parties in your construct reveal their keys before the beacon value is published (because NIST or whoever could just pick a beacon value that gives a particular result). However the new version includes a hash commitment in the current beacon for the next beacon, so participants could wait for that to be published, then share their keys now that the beacon operator can't change the next beacon value.