Yes this is basically what I was talking about. It becomes pretty tricky to understand memory layout if you try to masquerade as a regular type (hence my apparently controversial reference to JIT compilers). I guess my point is that Go pointers are language primitives for that reason, and they support the fundamental "safe" and "unsafe" access operations that all those other languages have. So I don't think there's anything fundamentally different between the safety of Go pointers and optional types, but they are easier to reason about from a memory model perspective (they are laid out in memory exactly as you would expect).
Relatedly, in practice, a lot of Rust code I've worked with is littered with unwrap() calls.
You only have to deal with the extra complexity if you choose to put non-pointers into an Optional, though. If you use the same capabilities go has, there's no problem.
Not that "maybe it uses an extra byte, maybe it doesn't" is going to matter in 99% of situations.
Relatedly, in practice, a lot of Rust code I've worked with is littered with unwrap() calls.