The UEFI spec already has provisions for making a variable inaccessible after BDS, just don't use the EFI_VARIABLE_RUNTIME_ACCESS attribute.
This functionality is specifically about protecting a variable from 3rd party code that is run during (or after) BDS.
If your variable needs BDS write access, don't do anything differently. Nothing is "locking all variables".

Regarding the concept of complexity and junior devs at an ODM, I would hopethat most organizations employ some form of code review.
Furthermore, I would hope that ODM features are designed with security concepts in mind.

Do we need to modify this variable outside of this code? If not, lock the variable.

There is nothing too complicated, all you need to do to protect a variable is call requestToLock() after you are done modifying your variable.
Everything else is done by the variable services code.

The way EDK2 and its vendors years before handles the variables was extremely unsafe, you can just hack the whole thing using user mode scripts, I cringed just by looking at the code. Now every silicon vendor binds their logic to make it safer (ME / PSP/ TPM / TCM or even BMCs), but still not safe enough, you can still make it through with a little bit grub knowledge, repository based data structure is always unsafe. The point is how you use it.

And don't forget we have dynamic PCDs which is abused by careless developers even more, a threat in the near future I might say.