Do you mind elaborating? I can see how the user's ability to 'place-order' might be rejected between the access check and the order creation but that would be an extraordinary edge-case that does not need to be accounted for in 99% of applications.
If you're developing an application that needs to account for such an edge case you could easily do so with an insert w/ join method on the Order model. The author isn't trying to show that the code is bulletproof for every scenario.
That's really the point. The code is deceptively simple for a whiz-bang "look how easy this is!" kinda presentation but the reality is that it's not useful for anything but a toy web store. Maybe it's fine that it only works 99% of the time if you're just trading Pokemon points, but not when you're dealing with people's money.
I'd argue being able to stop worrying about your code after writing it and not making decisions like these is a good enough reason to just do it right. Especially when it's not much more additional work
If you're developing an application that needs to account for such an edge case you could easily do so with an insert w/ join method on the Order model. The author isn't trying to show that the code is bulletproof for every scenario.