В принципе можно было и согласится, но смущает "статистика"Постоянно попадается что-то типа этого, но ни разу не наоборот.https://medium.com/javarevisited/just-dont-return-null-dcd...https://medium.com/@jadhavsid1101/why-returning-null-from-...

Фигня все это, от лукавого. Нет никаких причин не использовать null или любое другое (другие) значения, если они прописаны в доках функции. Более того, если есть только один единственный особый случай, то гораздо удобнее использовать null. Ну типа: "Край, ничем не могу помочь. Разбирайся сам."

В первой ссылке какие-то мантры. А по поводу аргументов из второй ссылке:

• Return an empty collection - Это не по теме. Мы говорим о значении, а не о коллекции. Автор съезжает с темы.
• Throw an exception. Это вообще другой холивар: return vs. exception. Опять автор съезжает да и проблему не решает, т.к. это надо ловить выше.
• Return an optional value. This way, the caller can use the optional value to check whether a value was returned or not, and handle the empty case appropriately. - Ну и в чем выгода? По любасу надо проверять возврат по поводу особого случая?
• Use the Null Object pattern. Здесь типа даже если ничего не возращено, то все идет по плану. Это вообще зашквар какой-то. Типа юзер не найден, но далее все идет по плану. Это как?
• Use assertions. И чем это отличается от явных проверок? Ну впрочем это лучшее решение, чтобы проверять отсутствие null во время выполнения если это нельзя проверить во время компиляции (как в Котлин например). Полезно, если null вообще невозможен. Но мы же говорим о случае, когда она возможен.

Основная рекламируемая выгода от этих наворотов это избежать nullpointerexception (это как срашный сон). Но я бы сказал, что этb средства означают заметать мусор под ковер. Надо наоборот: чем раньше такие nullpointerexception возникают, тем лучше, поскольку сразу видно кто где накосячил, а не ждать весны (релиза), чтобы видеть кто где насрал.