Your statement is false. Many use cases call for optional bools. The great thing is there is no implicit meaning - it's True, False or Unset. It is true that nulls can be abused but in this case, far more elegant than an enum.
Meanwhile if you see a `None` value you know for a fact that it was set by your software and if you actually encounter a `null` you know that something went horribly wrong.
Strong type systems and a few overheads in favor of better bug detection/prevention are popular for a reason.
Just use an enum, it's much more expressive.
Edit: grammar
In which case null would either mean the value on the recordin the database is null, or that that for whatever reasons that parameter was not read from the database.
You will need two types of null.
All of this goes away with an enum or similar solution.
You can decompose the nullable boolean in the database when you read it , but again your task would be easier to treat it like an enum.
Ditto for database design too