Да что это такое, ваше качество кода?

Читаемость - понятие заведомо субъективное. То есть то, что читаемо дня одного, совершенно нечитаемо для другого. Более того, в процессе ревью исходно нечтаемымый код становится читаемым, когда ты таки понимаешь, что хотел сказать автор.

Поэтому в некоторых коллективах MR принимается по факту наличия одобрения от нескольких ревьюеров

Есть такая тема - cognitive overload. Его очень просто добиться. Делаем много условий, пишем их в одной строчке, используем тернарные операции, хорошо бы вложенные.
Добавляем пару каскадов (типа LINQ в дотнете). И делаем всё в одном методе.
Вуаля! Теперь любой, кроме автора, а через пару месяцев и автор, потратит пару минут вместо пары секунд на то, чтобы понять, что там происходит

Ваше замечание верно. Именно поэтому нужно выбирать только такие критерии, с помощью которых можно провести четкую оценку, желательно выраженную числом.

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

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

А "простой" - это тот код, который читается без запинок в понимании. Но это не всегда равно эффективный, конечно же.

Характеристики "понятно" и "академически", сами по себе, довольно абстрактны и каждый человек вкладывает в них какой-то свой смысл.

Как всегда говорят классики: "Программист в такой момент руководствуется только своим чувством прекрасного".

Не важно как пишет программист: разляписто или элегантно, в одну строку или со структурой, применяя хакерские приемы или не применяя. Извечно все спрашивают только два вопроса: Что вы делаете? Зачем вы это делаете?

Ваше "Как это делают?" скорее риторический вопрос, чем математическое уравнение. Именно это и подчеркивалось в грубой, но меткой формулировке "Лучший код - это ненаписанный код", говоря о том, что часто лучшее решение там, где не требуются лишние проверки и формальности.

Да, вариант 5 самый читабельный.

Код пишется 1 раз, а читается много, поэтому важно, чтобы написано было так, чтобы его легко было читать, отлаживать, тестировать, расширять и переиспользовать. Для этого придумали Naming Convention, Code Style, комментарии, логирование, а так же подходы solid, dry, kiss, yagni, ...

По поводу Option.get, если делать правильно, то get вызывать не нужно никогда, но код превращается в функциональный, и кто-то считает это хуже Option.get, хотя я так не считаю. Если с Option делать и не писать все в 1 строку, то получится вполне читабельный код на функциональном языке.

public CompletionStage<Result> call(Request request) {
    return getAcHost(request).map(acHost -> {
        // acHost is set
        return getAccount(request).map(account -> {
            // account is set
            return getPage(request).map(page -> {
                // page is set
                return permissionService.canViewPage(acHost, account, page).thenCompose(canView -> {
                    if (canView) {
                        // authorized
                        return delegate.call(request);
                    } else {
                        return completedFuture(forbidden());
                    }
                });
                // page is not set
            }).orElse(completedFuture(unauthorized()));
            // account is not set
        }).orElse(completedFuture(unauthorized()));
        // acHost is not set
    }).orElse(completedFuture(unauthorized()));
}

От субьективности WTFs/minute никуда не уйти, даже оценки в школе мало коррелируют со знаниями. Есть книга Clean Code - одна из обязательных книг для программиста.

Очевидно, что понятие "качественный" у каждого из них свое. Но как понять, из чего оно складывается?

Парень, это так не работает. Нет там никакой прямой взаимосвязи между понятиями "качественный красивый элегантный код" и "эффективно работающая программа". Такой вопрос не решается вот так в лоб.

В технике вообще часто приходится идти на компромиссы, чтобы добится лучшего результата. В вашем случае, если хотите добится именно "эффективности", то оно решается средствами отладки, а не правилами кодонаписания.