Because Null only gives you one value, a value that doesn't tell you why it's null. In our company we have 3 values that replace null. The one closest in meaning to null is probably TBD (to be determined). It means the value is unknown at present, but is applicable and hasn't been verified as impossible to find out.
N/A (not applicable) means not only is the data missing, it's missing deliberately and will never be set because it doesn't apply to this record. For example, we have a Site table which contains an ATM field. However Sites apply to both ATMs (for replenishment/servicing) as well as places we perform courier work for (such as credit unions) that do not have an ATM. Thus the ATM field for the site is N/A. Null would be ambiguous in this context, is it null because it's never been filled in (somebody forgot) or because there is no ATM?
Finally, UNK (verified unknown) indicates that the field is empty because the data has been lost and is unrecoverable. One good example of this would be the purchase date for a piece of equipment so old we either lost or got rid of the purchase order.
Null in these cases doesn't work. It doesn't tell you why the field is empty, only that it is. For us, at least, that's not sufficient.
So we use magic numbers in domains that have naturally unused spaces. For example our date and date/time fields use dates of 01/01/1900 and before since nothing we deal with existed before 1900--including employees! :hehe:
For us the use of null and its magic number replacements are so critical our development wiki (everyone has a developer's wiki, right? :)) lists it as one of the first links on the development guidelines overview, along with the proper use of default values.