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
```java if (OPTIONAL.isPresent()) { return OPTIONAL.get().toString(); } return "OTHER"; ```	```java return OPTIONAL.map(Object::toString).orElse("OTHER"); ```
```java if (OPTIONAL.isPresent()) { x.DO_SOMETHING(OPTIONAL.get()); } ```	```java 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.