That's true, although like with rock paper scissors, ensuring simultaneous sharing of the keys is hard. So whoever reveals their key "last" knows the outcome before the other participants, which can be bad depending on the application. Adding a random beacon value from a 3rd party to the game (say as an input to the hash in step 3) means all participants can learn the outcome at the same time and that the reveal time is known in advance. Of course now it's the 3rd party that knows in advance, but for many applications you can trust them to be disinterested in the result and you can use multiple independent 3rd parties for better security.
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.
That part is to stop them from choosing the decryption key after sharing the encrypted strings with the intended result of guiding the outcome of the hash. If the content of the strings was wholly random a participant would be able to claim that the gibberish resulting from using a key chosen later was what they had meant to encrypt in step one.
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.