Unfortunately, the simple fact is that one can be handed a JSON document with non-existent keys, and one can be handed a database row with a null column. Often, the programmer may handed a schema from a third party they have no control over: opening a semantics debate is likely not a good course of action.
I guess since basic types, like an int or double, cannot be null, I understand why these cannot be null. This unfortunately limits their usefulness, but it's a carryover from the underlying properties of the basic type.
Value types will be optionally null. What java will introduce to the tooling is narrowing of nullness types. Hence Foo! <: Foo? <: Foo. This will assist in enabling safe domains or scope in code that are null-restricted with ease. Hence we can model around such a type system rule.
I guess since basic types, like an int or double, cannot be null, I understand why these cannot be null. This unfortunately limits their usefulness, but it's a carryover from the underlying properties of the basic type.