This is likely minutia and the answer is probably pick one and stick with it.
I call these fields indicators or "is" fields. I name them like isCustomer, isVendor. It keeps them all nicely grouped in alpha order and read well for me in code. for example.
if [ people::isVendor ]
if [ not people::isCustomer]
Because most script steps and functions see both, null and false as false, I don't run into too many issues with this. I did recently with an extend found set where one condition was that a valve be null. I was using a boolean toggle that was
set field [people::isVendor ; not isVendor] to toggle the boolean. that script step reads more clearly to me than
set field [people::isVendor ; if( people::isVendor ; 1 ; "" )
but I in a find, = and 0 do not return the same results (unless there is a way to find both. )
I need to choose to autofill a false boolean field with a 0 or script all my toggles to be sure to set a null instead of not.
One minor point for using the null is that my most used value list that only contains 1 for checkboxes natively leaves a null when checked and unchecked.
I am guessing that using a null will get slightly better performance and using the false will be a little easier to code. That being the case, I choose the negligible performance gain I guess.
Thanks for indulging me!