First of all I do appreciate your comments and lots of thoughts you are expressing I had myself at anytime as well. I changed the example already on a few points because of some of the just comments.

I do really see where you are coming from. Although do not think the paradigm of exception handling and fault barriers are always what should be used in cases like these. In lots of applications there will be lots of optional/nullable objects. Using an Optional is an ideal way to implement code where you can both implement paths for the case where there is or is not a certain object present, both representing valid healthy situations within the application. Often there are so many permutations of optional/nullable objects that you can not speak of one happy flow and it would be really irritating to throw and catch exceptions' for all these cases that are really normal program situations.

Debug and or trace logging could support understanding what happens in an application, even if there is not a real error or warning situation. So I still think this usage is valid, but if it all depends on readability and adoption. I'm sure if an often-used library like the Java API or commons-collections would offer some more options they might rapidly become popular.

Thanks for your fierce criticism so I can improve my question :-)