Earlier quoted context omitted.
The type system knows about it and you're forced to check it
Right, but my point is, the code which would raise an error because the pointer is nil now raises an error because the Optional is not set. Is there really that much of a difference between those cases? I agree though that in an interface, Optional conveys a more explicit meaning than something pointer-like, which is always a good thing.
Go programs crash at runtime. In general, program failures and bugs should surface as soon as possible. Ideally no later than compile time. Instead, Go makes you wait until the app is running.
For an app that has a lot of configuration options, for example, there can be a latent bug that crashes the binary for some options. And that bug may not be detected for months because nobody was using that combination of config options.
The only real defense of this is to pepper your code with a bunch of nil checks. But these nil checks are also hard to test, so Go devs just learn to ignore missing code coverage. In fact, your code coverage metrics look better if you don't check for nil.
I'm sure at some point Go or a library will offer a version of optional types that is well-adopted. But my point is that by the time Go was designed, null references were already widely considered a bad idea and the source of a huge class of computer bugs. Go still deliberately designed them into the type system.