If you don't have null pointers then you need to push the responsibility for checking for initialization somewhere. You seem to be advocating that place is in the type system. That's fine, but you can't say it wouldn't make the type system more complex.
I see more Go code than probably anyone in the world, and I don't see anyone suffering from the scourge of null pointers, however bad people say they are. I think in certain contexts they can be problematic (SQL is a good example), but the concept of "nil" in Go is quite useful and easy to understand. For instance, unlike C++ it is quite valid to call a method on a nil receiver.
> Tell me again, how does allowing null references lead to "simple code that is obviously correct"?
It's a tradeoff. You get a simpler type system in exchange for null pointers.
> More complexity for the language implementers; less complexity for the language users.
No, not just for the implementers. For the users too.