While I'm quite an advocate of using NULL values instead of magic values, due to the slightly interesting way that NULL values are handled in comparisons and sorts there are times when magic values are more appropriate. These cases usually revolve around the situations where non-technical users use and require fairly direct access to the data, usually for reporting purposes and usually date based columns. While it's easy enough to create views into the data and through these effectively implement magic values for these columns this process adds another administrative burden to a system.

For the majority of non-date/time based there really shouldn't be a need for magic values. Sometimes pseudo-magic numbers are useful though, for example where a status lookup ID has an implied order where for example 0=don't know (default, non null) and 999=hell yeah, it makes queries rather simpler if they can be ordered by the ID direct rather than a sort column in a joined lookup table. Again, this situation could be handled in a view to make life easier for end users but as above this adds an administrative burden (and also makes query optimisation a little more involved as well).

So I'd say that it's best to avoid both magic values and NULL values where possible. Magic values should really be handled using lookup references and default values (this tends to be hard with date/time columns) and NULLs avoided unless you genuinely need to record that no value has been provided, just beware of the consequences.