If you use the BeforeUpdate event of a control, you still need to check first for Me.NewRecord since the code we are discussing should NOT apply to an existing record.
The BeforeUpdate event of a control is not terrible but it still requires the user to enter all the text of at least one field rather than just a single character. I'm not sure why you think this is better but it isn't nearly as bad as letting the user enter the entire record before rejecting the input.
Personally, I rarely use the BeforeUpdate event of a control since that event is not capable of ensuring that data is actually entered so rather than split up the validation code for each field, I do it all in the BeforeUpdate event of the FORM where I can ensure that required fields are present, related fields are proportional (i.e. Start Date <= End Date), and any other requirements are met.
Given all that, I would use the BeforeUpdate event of a control if I needed to prevent duplicates. For example, entering a SSN. If the application does not allow duplicate SSN's (and it shouldn't), it is less confusing for the user to check this immediately rather than allowing the entire record to be entered before looking to see if the SSN already exists.
The various control and form events were designed for specific types of processing. You can get away sometimes with doing things in an event intended for a different purpose but there is always a price to pay.
I found a horrendous example of this a few years ago. An app I took over was saving incomplete or even invalid data. I examined the code and found THOUSANDS of lines of duplicate code. The programmer had noticed the problem and tried (unsuccessfully) to fix it. He went as far as validating EVERY field in several control events of EVERY control. So he validated up to 50 fields * 6 control events (Click, Dirty, Change, Lost Focus, Mouse Up, Exit) * 50 fields. fld1 validated fld1. fld2 validated fld1 and fld2. fld3 validated fld1, fld2, and fld3, etc. And this was repeated in multiple forms. So we got up to about 10,000 lines of useless code. The code was useless because NONE of it was in either the control's BeforeUpdate event or the Form's BeforeUpdate event where it belonged. So the code raised lots of errors but never stopped the bad data from being saved. It also caused a certain amount of confusion because he was sloppy about managing the tab order so on a couple of forms, fld6 was earlier in the tab order than fld4 so flds5 & 6 were being checked for null before they could reasonably be expected to be present.