Null, великий и ужасный

NRE раз в неделю — это ровно на один раз в неделю больше чем нужно. NRE в продакшене вообще недопустимо.
Проблема именно в том, что разыменование любого ссылочного типа может бросить исключение.

1. Если null в этом месте не нужен, то гораздо лучше поддерживать non-nullable типы с помощью компилятора и не иметь NRE.
2. Если null в этом месте возможен по бизнес-логике, то гораздо лучше требовать обработку обоих случаев (наличие и отсутсвие значения) на этапе компиляции и не иметь NRE.

Я конечно, стараюсь null не возвращать и не передавать, но это на уровне смысла методов скорее, чем претензия к языку.

Можно, но не нужно. Нет смысла проверять на null там, где по логике требуется наличие значения.

var r;
var foo = getFoo();
var bar = getBar();
if(foo != null && bar != null){
  r = calc(foo, bar);
}

r = do
  foo <- getFoo
  bar <- getBar
  return $ calc foo bar

Где тут проверка на IfPresent?

Основная тема статьи: не как отказаться от null, а как избежать ошибок разыменования и сделать это как можно раньше.

Что там, кстати, с NULL в sql, не надумали отказаться?

В sql с null-значения проблемы другого рода: можно получить проблемы с производительностью (например, oracle не индексируют null-значения), можно легко сделать логическую ошибку в предикате запроса (троичная логика не всегда очевидна). И отказ от null — одно из возможных решений.

Все (по крайней мере должны) проверяют входные параметры в функцию и выходные из функции.

Да, восемь строк проверки на три строки полезного кода смотрятся просто, чисто и элегантно.
Проверки выходных параметров и возвращаемых значений в коде не припоминаю за все время работы.
Посмотрите решение 11 — оно справится с проверками лучше программиста-человека.

Почему if(something != null) вдруг „антипаттерн“? Единственное назначение которого — выбросить исключение поближе к месту предательства“ — никто не выбрасывает NullReferenceException и никто не отменял валидацию параметров метода (InvalidArgumentException) или ошибочных сценариев (InvalidOperationException).

в «исторической альтернативе» все как-то, извините, «сдулось» в один маленький абзац.

А там и не требуется сильно больше: источником серьезной проблемы стала экономия буквально на спичках. Добавил примеры кода к альтернативе.

Сухие перечисления без примеров — бесполезны, никто не будет «заучивать» их наизусть, без понимания почему так.

В этом случае каждое решение грозит превратиться в отдельную статью, что повысит трудоемкость для меня и ухудшит усвояемость для читателей.
Я не стремился подробно осветить каждый нюанс каждого частного случая. Моей задачей было дать обзор типовых проверенных решений и высокоуровневые критерии для их выбора. Для тех, кто хочет узнать больше о конкретном варианте — в тексте есть ссылки.

Проблема не в том, есть null или нет, а в том что

1. null допускают все типы полей в БД
2. Операции с null ведут к ошибкам при исполнении а не при компиляции запроса.

Если бы значения integer null и integer not null были бы

1. разных типов,
2. не совместимых между собой без явного coalesce
3. с доступом к большинству операций только для integer not null,

то с null и в SQL было бы намного меньше проблем.