Refactor some usages of Optional

[guillermocalvo]

Now that Optional instances are unified, we can refactor some usages to simplify and hopefully make the codebase easier to understand and maintain.

Examples

Before refactor	After refactor
if (OPTIONAL.isPresent()) { return OPTIONAL.get().toString(); } return "OTHER";	return OPTIONAL.map(Object::toString).orElse("OTHER");
if (OPTIONAL.isPresent()) { x.DO_SOMETHING(OPTIONAL.get()); }	OPTIONAL.ifPresent(x::DO_SOMETHING);

Note

Merging this PR should not add new features or alter existing functionality in any way. The main goal is to avoid both conditional branching and unwrapping optionals if the code is more readable without it. This results in a more idiomatic usage of Optional and reduces cyclomatic complexity.

@siom79 Please let me know your thoughts about this refactor. I understand readability may be subjective; there's no need to merge any of these changes if you are uncomfortable or unsure about them.