Values for Boolean fields can only be stored in the database as true/false, but there is the third option where no value is stored at all. This results in a field that is trinary (true, false, no response) rather than binary until a value is stored. Once a value is stored, the field is a true binary.   It is expected behavior that Boolean fields are null ("no response") until touched.   The default value is null because you could have a situation where automatically setting the value to "false" could create problems. An example would be a field for "Accept Phone", where "false" has a very different meaning than "null/no information".

This means that any records created before you added the custom field, and records that have not had this field edited, will have a null value for the field.  Therefore, you'll want to use "not equal to true" for your queries, rather than "equal to false" in order to include the constituents that do not have a response for that field.  Whether that will get you the info that you need will depend on the information you're holding in the field. 

In the case of an "Accept Phone" field, you could use that field to pull three different groups of constituents for an upcoming telemarketing campaign.  Depending on your organziation's business rules, you could pull those lists as follows:
  1. Include only those constituents who have explicitly opted in to receiving contact by phone: "Accept Phone equals true"
  2. Include anyone who has not explicity opted out: "Accept Phone is not equal to false"
  3. If you are pulling a suppression/Do Not Call list, you would probably limit that list to just the constituents who have opted out: "Accept Phone is equal to false"