While I agree that Optional.get defeats the purpose, one thing it does ensure is that one is a lot more stringent about defensive checks where one needs to be.
In an ideal world, I really should not be needing “optional” fields and defensive checks, but the harsh reality is that most Java codebases and libraries around are full of code that essentially allow null values. When I do see that the signature of something is Optional<T> rather than a T, it is that much more likely that I will actually do a defensive check on that variable.
Ideally of course, I would simply use an Optional wherever there is a chance of a field being not present, and use maps and filters with functions to operate on it; the functions are inherently testable as a nice side-effect.
While static analysis is awesome, we unfortunately use a lot of old (and at times bad) code; for this alone, I would opine that it is a good idea to wrap any new wrappers around this in Optionals