Вы всё ещё ловите исключения? Тогда мы к вам

Когда код что-то вызывает, он определенно имеет отношение к тому, что вызвал. И к ошибкам этого в том числе.

Вызывающий код абсолютно не обязан обрабатывать ошибки вызываемого кода, а может делегировать это обработчику более высокого уровня. Пример из Java:

public class DataOutputStream extends FilterOutputStream implements DataOutput {
    public final void writeInt(int v) throws IOException {
        out.write((v >>> 24) & 0xFF);
        out.write((v >>> 16) & 0xFF);
        out.write((v >>>  8) & 0xFF);
        out.write((v >>>  0) & 0xFF);
        incCount(4);
    }
}

Здесь метод writeInt() вызывает OutputStream.write() аж 4 раза, при этом ни нет одного обработчика! Таким же образом любой код вправе сохранить "оптимистичную" модель программирования, не заботясь о завершении каждой "небезопасной" операции, и не замусоривая код обработчиками и логикой, которая не относится к этому методу. Здесь обязуют декларировать checked IOException, однако если бы тут был RuntimeException декларация отсутствовала бы. И такой код вполне себе имеет право на существование.

Сбой операции — один из возможных исходов операции и он входит в контракт этой операции. И корректное обращение со всеми исходами — это часть ответственности вызывающего.

Это ошибочное мнение.
Во-первых, как я уже сказал, вызывающий метод отнюдь не несет ответственность за обработку возможного исключения, если это въявную не предусмотрено его бизнес-задачей.

Во-вторых, вы никогда не сможете обработать все ошибочные исходы, ибо их множество в общем случае вычислимо, но никогда не определено ни одним контрактом. Я имею ввиду всевозможные RuntimeException, которые могут возникнуть в вызываемом коде, особенно если имеете дело со сторонней библиотекой/фреймворком, где под капотом подмешано большое количество различных технологий. И это множество зависит от многих факторов, многие из которых определяются не кодом, а runtime-конфигурацией системы: для одного и того же интерфейса может быть куча разных подключаемых провайдеров, код может работать в транзакции, вызывать remote-методы, делать RPC, стучаться в базу — и везде есть чему вальнуться. Поскольку конфигурация динамическая, на этапе проектирования нет возможности определить все возможные варианты сбоев.

В-третьих, сильно завязывать бизнес логику на исключения — это заведомо плохой подход. Exception — это именно исключительная ситуация, которая говорит о невозможности выполнения операции и требует раннего завершения всей цепочки вызовов. Если аварийное завершение — это часть вашего контракта и предусмотрена бизнес логикой, то и возвращайте его как обычное значение. Например вместо NotFoundException или NullPonterException возвращайте обычный Optional или на худой конец null.

Это отличается тем, что Either вы обязаны либо распаковать, либо передать в Either-aware функцию. Вы не можете просто передать Either<E, int> в функцию, которая хочет int, потому что ваше приложение просто не соберется. Вы не можете получить из Either одновременно и Left, и Right-значение, так как у Either есть только одно, и вам предстоит как раз узнать, какое. Почему именно так, видно на примере ошибки дизайнеров golang, которые распаковывают результаты функций в err и value автоматически, благодаря чему err можно смело игнорировать, а в value может быть мусор (и вы об этом не узнаете).

Но если ваша функция что-то выбрасывает, то вы можете передать ее результат куда угодно, и если функция при этом вылетит, вы рискуете ничего не словить, потому что вы не были в курсе, что вам что-то в принципе нужно ловить. А раз вы исключение не словите, то оно полезет вверх по стеку и в лучшем случае обрушит сервис, а в худшем будет словлено чем-то не тем, и приложение перейдет в неопределенное состояние.

Это хорошее поведение для незапланированных ситуаций (закончилась оперативка), и плохое для штатных ситуаций (мамкин хакир прислал нам обрезанный пакет).

Что касается ловли подклассов — вы можете в Left-части Either передавать экземпляры классов с произвольной иерархией и тестировать их каким-нибудь instanceof на принадлежность к базовому классу. То же касается приоритета и порядка.

Бросать исключения, чтобы срезать путь и тем самым нарушить инкапсуляцию, создав протекающий интерфейс, который может себя вести произвольным образом, считаю порочной практикой.

Если компонент в глубине коллстека не знает, что делать с ошибкой, то ошибка ли это? Почему компонент в глубине стека считает, что если пользователя нет в БД, то это ошибка, которую он обязан выбросить, а не просто вернуть пустой Maybe вызывающей стороне, и пусть уже бизнес-логика с этим разбирается?

Именно так. В отличие от go, где err и value извлекаются из результата функции автоматически при ее вызове, и про err элементарно забыть, вы не сможете провернуть этот же фокус с Either. У Either есть только одно значение — это либо left-значение (ошибка), либо right-значение (результат), и вы не можете извлечь оба сразу. Вам нужно статически решить, что вы делаете, и обработать оба варианта, иначе ваша программа не соберется.

Ну или передать Either как есть в функцию, которая явно принимает аргументом конкретный типоэкземпляр Either.

К тому, что по поводу дизайна исключений есть мнение первоисточника, на которое я и сослался. Как оно зависит от версии — не знаю. На мой взгляд, никак не зависит. 8 версия сегодня самая актуальная.