Interesting.
Yeah, Emmanuel seems to have said as much in that 5-year-old post.
That said, something did just occur to me, which seems plausible at first blush (but maybe not “fair”)…
If the core issue is timing-related, perhaps one way to address it is by injecting some randomness at the appropriate times. So for example, once the registration reaches some threshold - let’s say 85% of capacity - during a high-demand period, then start randomizing the workflow executions within a span of several seconds in an attempt to “spread out” the DB writes associated with [nearly] concurrent incoming requests.
Yes, it means the last few “slots” might not be filled in exactly the order they were requested (and someone who actually pressed their enter key before someone else might miss out), but maybe that’s acceptable in some situations.
And of course, the user might be waiting for a few seconds, but just display a busy message:
Demand is high. Checking availability…
…along with maybe a slot machine animation. 
I’m sure it still wouldn’t guarantee no race conditions, but I wonder if it would be an improvement. 