Why would I (or you, or anyone) actually APPRECIATE, much less graciously accept the programmatic question "Does x = null?" being answered with 'UNKNOWN' (e.g. "I'm sorry, Dave. I can't answer that.")?
Sorry, missed that part of your question in my first reply.
First: In the literal sense as presented here, getting true or false on an "= null" test would indeed make sense - but it would be inconsistent behaviour (more on that below). For the literal case IS NULL (and counterpart IS NOT NULL) is provided. Slightly more typing than = NULL or <> NULL, but still a lot less than the average COBOL program used to be.
Second: The consistency issue. Tests are often made between variables and/or columns instead of literals. So you might have a query that returns all people younger then me. You query my age, store it in a variable, then select people with Age < @HugosAge - or you use a subquery for the same effect in a single statement. So, what rows should be returned? All of them? None? Only some? No matter what answer you give here, the chance that you get it right is very small.
When the SQL language was designed, the creators had to find a standard answer for this question, that would be applied in all situations. Returning some rows makes the least sense, so there are only two viable conditions: return all rows where the predicate evaluates to Unkown (give the benefit of the doubt), or return none (prevent false positives). They chose the latter. The alternative would have been at least as confusing - maybe even more.