The before commit should not allow your Order object to be commited if you returned false. Are you sure that your return value is false and not just the equation you make? Look at your end point what does it return? Also debugging can help you here. Set a breakpoint on your before commit to see what it actually returns. As said earlier, if it returns false it should not commit the object.
Check it before you save the object by using a microflow instead of a default save button.
In that microflow you can use a show validation feedback action if something is wrong, or a change & commit activity if everything is OK.
In the event microflow I retrieved the Customer from the database instead of from association. The effect is an implicit commit of the Order during the event, thereby bypassing the event handler. Returning false after the commit has no effect because the Order has already been saved.
Now I'm just wondering if this is what we want. Event handlers are meant to safeguard data integrity. Should it be possible to inadvertently bypass them and ruin your data?
Unfortunately, breakpoints don't seem to work in the trial version, but the Show Message action just before exiting the microflow confirms that it returns either true or false just as I expect it to do.
I know the Before Commit event gets fired at the right time and that it returns the correct boolean value. Could it be possible that the trial version doesn't respond to return values of event handlers?