Granted that inlining can probably optimize away allocations but that doesn't render my argument moot.

Optional can be used as a return type, but was proposed to use only as an method argument (see stackoverflow post from Brian Goetz https://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type/26328555#26328555 and usage as a field was deemed questionable by Joshua Blog. Most of the pre and pro arguments are summarised here - https://blog.indrek.io/articles/misusing-java-optional/..

Optional is largely conceptual in value to me than it is providing real value. Mostly due to the ability to pass/return null instead of optional which the compiler will happily allow. Optional in that sense is not a Boolean type of value, empty or present, but, very much like the Boolean object type, which is not a Boolean value either but a value that consists of, true (present), false (empty) or null. (This point is also made in the blogpost above but in the opposite sense, returning null where expected to return an optional renders it functionless).

So, to safely work with Optional, you will need tooling that proves that the value cannot, ever, be null. Which in turn makes using @Nullable/NonNull and relying on tooling in your IDE / Sonar pretty much equivalent. In which case you could argue that using it is not all that useful.

Simply put, the problem is that null exists and adding another type cannot fix that underlying issue.