Nulls are evil. The only place I use them is for optional human-readable comments. Null means "no value". It doesn't even tell you why the value is missing. The context of an optional comment makes the meaning of null obvious in context: nobody could be bothered to add a comment. 🙂
The pro-Null folks like to deride magic numbers as tribal knowledge, and there is a little justification for that. However, like all magic numbers, the cure is to document them. Since nulls are such a fundamental design decision any null-replacement should be A) set in concrete and B) consistent across the all apps in the company and C) beaten into developers heads with a clue stick the instant they join the company.
In effect the purpose and use of null replacements should be as consistent as 0 is in mathematics, at least within the company.
Yes, you do have to code for null replacements BUT if you're clever about it they're much easier to deal with than nulls. Having at least 3 replacements for null (i.e. "to be determined" (the typical use of null), "not applicable" and "verified as unknown" (i.e. the data was lost and there's no way to recover it)) gives "null" a much more useful purpose than null meaning "duh, no idea why it's missing". Of course specific companies may need a wider array of null replacements.
YMMV, of course.