It's a monstrosity because the underlying language design makes it necessary. A whole class of bugs could be eliminated if the language didn't allow you to have null references, and instead, made you explicitly state your function might not return an object, for example, the Maybe datatype in Haskell.
You can argue that null references are problematic and I'll agree with you. But they're a part of Java (and a whole host of other languages, too) and that's not going to change anytime soon.
Saying that this is "a monstrosity" because nulls shouldn't exist in the first place is completely unhelpful. Whether we like them or not, we're going to be stuck with them for a long while, and attempts to make them less painful to deal with aren't a bad thing.
Examining existing languages is useful to advance the art in computer language design. Being "stuck with them" just means we have the experience of writing software with these features.
In addition, there's no reason we can't write a language without nulls which works on the JVM.
But we're not talking about advancing language design--we're talking about a small modification to an existing, widely used language whose basics are not going to change. There are a lot of problems with Java I'd like to see fixed before null, and the Java community has dismissed most of those as too radical (like closures).
There are languages which work (mostly) without nulls on the JVM though. Scala does something very similar to Haskell's Maybe. (Although for interoperability with Java it can deal with nulls if you insist.)
