было немного времени потщательнее обдумать твои вопросы)
извини, тормозила. Длинный день)


в Selenium есть классы
public class WebDriverWait extends FluentWait<WebDriver>
и его предок
public class FluentWait<T> implements Wait<T>


на уровне интерфейса Wait<T> - объявлен метод
<T> T until(Function<? super F, T> isTrue);
который реализован  на уровне класса FluentWait

и этот метод until, собственно, реализует ждущую проверку =
выполнения некого условия Function<? super F, T> isTrue

и вот эта сущность - Function<? super F, T> isTrue
типизирована двумя разными типами
как дженерик-типом T,
который определяет - какого же типа результат будет получен при вызове метода apply
у нашей сущности isTrue

так и типом - ? super F
который определяет тип параметра метода apply

Сущность isTrue - это объект, который имплементирует интерфейс  Function
Вот описание интерфейса Function
https://github.com/google/guava/blob/master/guava/src/com/google/common/base/Function.java

А это значит - что у такого объекта будет реализован метод T apply(@Nullable F input)

Который в методе until - мы как раз вызываем - чтобы в очередной раз проверить - выполняется ли нужное нам условие.
В Selenium очень много всего работает с использованием вебдрайвера
И логично предположить - что и для многих проверок он понадобится (возможно, не для всех, но для подавляющего большинства - так точно)
Потому - нам нужен вебдрайвер на этапе - когда для нашего кондишена - мы будем выполнять проверку = вызывать метод apply (см релизацию until)

Когда мы реализуем объект-кондишен, то нам в его конструктор и не нужно передавать вебдрайвер, мы с ним и не работаем в этот момент.  А вот метод  apply  у этого объекта - мы реализуем с параметром типа WebDriver. И мы внутри этого метода apply - реализуем некие проверки (как правило, задействуя WebDriver). Посмотри на реализации родных селениумских кондишенов - как на примеры
https://github.com/SeleniumHQ/selenium/blob/master/java/client/src/org/openqa/selenium/support/ui/ExpectedConditions.java

Тот вариант, что ты приводил выше -

public static ExpectedCondition<WebElement> visible(final WebElement element) {
    return webDriver -> element.isDisplayed() ? element : null;
}


фактически, равносилен коду с использованием анонимных классов
    public static ExpectedCondition<WebElement> visible(final WebElement element) {
        return new ExpectedCondition<WebElement>() {
            public WebElement apply(WebDriver webDriver) {
                return element.isDisplayed() ? element : null;
            }
        };
    }

вот наш вариант метода http://joxi.ru/l2ZNaR0F80d0z2
и IntelIJ Idea - позволяет свернуть код = спрятать детали http://joxi.ru/Y2LXgYnfnR4Rn2
Нажми “+” слева от кода (для строки 15 на скриншоте) - и увидишь код - как он есть

А в 8-ой Java - уже поддерживается изначально вот такой синтаксис и возможности функционального программирования. Но это уже совсем другая история)

Мы определились - что у кондишенов - метод apply - получает как параметр вебдрайвер и как правило - оперирует им (в данном случае - для visible() - как раз нетипичная ситуация - нам вебдрайвер не пригодился, но ты легко можешь оценить - как часто такое случается - если посмотришь на реализации кондишенов в классе ExpectedConditions https://github.com/SeleniumHQ/selenium/blob/master/java/client/src/org/openqa/selenium/support/ui/ExpectedConditions.java)

Итак - в until - мы передаем объект-кондишен
    у которого есть нам нужный в until-е  метод apply(WebDriver webDriver)
        который позволит выполнить некую проверку
            которая как правило без вебдрайвера невозможна)

Откуда мы для вызова apply - берем вебдрайвер
    оттуда - где мы вызываем apply - в until
        А это метод какого объекта - WebDriverWait or FluentWait
            Таким объектам - мы как раз в конструктор - и передали вебдрайвер)

Надеюсь, от этих пояснений станет чуть проще и я в них осветила твои вопросы)