Да, вариант 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 - одна из обязательных книг для программиста.

Вариант 1

• Используется Optional.get значит уже что-то неправильное происходит, либо вам не нужны Optional. 1 WTF.

• Вложенные IF когда это можно избежать. 1 WTF

• thenComposeAsync да еще и в commonPool! Тут вопрос насколько автор действительно хочет следующий stage запускать всегда в другом потоке из commonPool, а не в том же потоке в каком логика canViewPage. permissionService тоже ведь асинхронный и тоже что-то запускает в другом потоке. Так зачем эти прыжки из потока в поток? Тут 3 WTF.

Вариант 2

• permissionService.canViewPage возвращает Optional<CompletionStage<Boolean>> что-ли? Может и не возвратить stage? Тут ошибка дизайна какая-то ради flatMap. Сразу 10 WTF

Вариант 3

• Function3 - ошибка дизайна, надо создать класс с нормальным именем, вроде SecurityRequest, в котором будет 3 поля и он будет передаваться в canViewPage. 10 WTF

Вариант 4

• Tuple - 10 WTF, то же самое. Никаких Tuple, если это не математические вычисления, быть не может.

Вариант 5

• orElse(null) как раз и говорит, что Optional, по крайней мере тут в API, не нужен. На уровне синтаксиса java не смогли сделать как в Kotlin, дали костыль - Optional.

Еще нет логов.

Там static import на CompletableFuture? Очень сложно ревьюить. Имхо это оправдано только в тестах, где очень много Mockito и все понимают, что это static import.

public CompletionStage<Result> call(Request request) {
    ACHost acHost = getAcHost(request);
    if (acHost == null) {
        log.debug("Request(id={}).acHost is empty: unauthorized", request.getId());
        return CompletableFuture.completedFuture(unauthorized());
    }

    Account account = getAccount(request);
    if (account == null) {
        log.debug("Request(id={}).account is empty: unauthorized", request.getId());
        return CompletableFuture.completedFuture(unauthorized());
    }

    Page page = getPage(request);
    if (page == null) {
        log.debug("Request(id={}).page is empty: unauthorized", request.getId());
        return CompletableFuture.completedFuture(unauthorized());
    }

    return startAsync(start -> start
            .thenCompose(unused -> {
                log.debug("Request(id={}) processing: acHost={}, account={}, page={}",
                        request.getId(),
                        acHost,
                        account,
                        page
                );
                return permissionService.canViewPage(acHost, account, page);
            }).thenCompose(canView -> {
                if (canView) {
                    log.debug("Request(id={}) authorized", request.getId());
                    return delegate.call(request);
                } else {
                    log.debug("Request(id={}) forbidden", request.getId());
                    return CompletableFuture.completedFuture(forbidden());
                }
            })
    );
}

startAsync - это такая штука которая лямбду всегда зпускает в другом потоке. Вначале создаем цепочку stage, потом запускаем в каком-нибудь execution service.

public CompletionStage<Result> startAsync(Function<CompletionStage<Void>, CompletionStage<Result>> closure) {
    CompletableFuture<Void> start = new CompletableFuture<>();
    CompletionStage<Result> cs = closure.apply(start);
    start.completeAsync(() -> null, es);
    return cs;
}