Java does not have a full FP story, so to bastardize newer code as though it does becomes unreadable IMO. The "and" was just for the example, since "..." wouldn't have made it clear. I do not find it more readable personally, but that is a personal opinion. Because other code eagerly returns (doesn't usually bother me in an imperative language) is a different problem with code path complexity that can be addressed elsewhere. There is still a practicality in normal conditionals and traditional linear paths.
I don't disagree that FP doesn't feel complete in Java yet. But that doesn't mean I'm not totally willing to start playing with what I've got!
The biggest worry I have right now is the story on debugging code with Optional bastardized FP. I know I'm going to learn some lessons soon enough, lol.
Comparing your code and mine, I ask you this: which one do you thing is more maintainable after 5 years of edits?
Each time a new developer needs to add a new case, a new rule, a new whatever, on my Optional (ab)usage, they just add a new line in the appropriate spot, a .filter or a .map or whatever. In yours it's far less clear.
Optional, for me, is wonderful because it lets me have a single return statement. A lot of the code in Java I'm replacing with this pattern is the stuff that has 5 different returns after checks. Crusty old stuff, but the business logic it's running has grown the way it has for good reasons.