Onde Optional deve ser usado, e onde ele é um erro?

Optional foi desenhado como tipo de retorno para métodos que legitimamente podem não ter resultado, para que quem chama não consiga ignorar a ausência. Ele é um encaixe ruim para campos, parâmetros de construtor e argumentos de método, e não deve embrulhar uma coleção, já que uma lista vazia já diz que não tem nada aqui. Chamar get sem checar derruba o propósito; use map, filter, orElseGet ou orElseThrow com uma exceção significativa.

Ele existe para que a assinatura de um método consiga dizer que isso pode não retornar nada, coisa que um retorno nulável nunca comunicou. Então buscas em estilo de repositório retornam um Optional e quem chama é obrigado a lidar com isso. Onde dá errado é quando as pessoas colocam ele em todo lugar. Como campo ele adiciona um objeto por instância e não é serializável, o que causa problemas reais em entidades e payloads. Como parâmetro ele só dá a quem chama três estados para pensar em vez de dois, então eu uso uma sobrecarga no lugar. E um método que retorna uma coleção retorna uma coleção vazia, nunca um Optional de lista, porque vazia já significa a mesma coisa. Em termos de estilo, se eu escrevo isPresent seguido de get eu acabei de escrever uma checagem de nulo com cerimônia extra, então eu encadeio: map para a coisa que eu quero, filter, depois orElseThrow com uma exceção de domínio que diz qual id não foi encontrado. A única coisa que eu não faria é usar ele como substituto genérico de nulo por uma base de código existente, já que o estilo misturado é pior do que qualquer uma das convenções sozinha.