да, люди тут знают об этом

jee мертв

все отлично описано в доке и тонне статей

часто путают интерфейс, как конструкцию языка Java (ключевое слово interface) и интерфейс, как абстрактное понятие.

У каждого класса, вне зависимости от того, имплементит он какой-либо Java interface или нет, есть публичный интерфейс (публичное API). Это его публичные методы. Выделен ли отдельный интерфейс в смысле ключевого слова interface или нет - не имеет значения. От этого класс не перестанет иметь публичное API.

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

Если у вас будет класс с двумя публичными методами, то эти 2 публичных метода - и есть интерфейс данного класса. Можно его вынести в виде отдельной Java-конструкции interface, а можно не выносить, если не планируется API данного класса предоставлять внешним модулям (т.е. "клиенты" данного API находятся в том же jar-нике) или делать более одной реализации.

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

Ну и, может быть еще, для самоорганизации: т.к. методы интерфейса все пустые, то беглого взгляда на содержимое файла достаточно, чтобы увидеть его API. В классе же может быть много методов, они могут быть не очень маленькие, часть из них приватные (не являющиеся API-интерфейсом данного класса) и т.п. - сложнее взглядом охватить "интерфейс" данного класса (но это не значит, что его нет).

еще для TDD интерфейсы нужны

не обязательно же. делайте пустой метод с TODO() внутри и готово

ну это часто еще и к культуре организации кода. выделение абстракций

Вы пишите, что у каждого класса, вне зависимости от того, имплементит он какой-либо Java interface или нет, есть публичный интерфейс (публичное API). И это инкапсуляция.
В интернетах пишут - инкапсуляция означает, что внутреннее представление объекта обычно скрыто от взгляда за пределами определения объекта. Абстракция -это механизм, который представляет существенные характеристики без включения деталей реализации.
Не могу все-равно понять почему допускается делать зависимости от конкретных классов, учитывая, что инверсия зависимостей  требует чтобы высокоуровневые модули были независимыми от низкоуровневых. Так как бизнес логика это главное, то это контроллер(конкретный класс) инжектит сервис, а не наоборот, и сервис с бизнес логикой в свою очередь не должен знать про сервис отправки почты, так как отправка почты это второстепенная логика нижнего уровня, странно было бы если при изменении методов отправки почты нам пришлось бы менять код классов с бизнес логикой (и вероятно получить опасные ошибки), а если есть интерфейс, то можно сделать адаптер и бизнес правила будут нетронуты.

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

Если интерфейса (именно Java-файла interface) нет, то можно сделать все то же самое.

Если вдруг выявили необходимость сделать адаптер, то в любой момент можно сделать Extract interface, и только что MailSender был классом, как вдруг он стал интерфейсом, а вся реализация уехала в какой-нибудь MailSenderImpl или SmtpMailSender (если допустим отличительной особенностью данной реализации является то, что она использует протокол smtp). И появилась рядом вторая реализация MyNewFancyMailSender, имплементящая тот же интерфейс MailSender, но под капотом делающая что-то другое.

Т.к. все это в пределах одного модуля, то это нормально. Незачем преждевременно усложнять.

К тому же, на практике в 95% случаев все равно интерфейс нового MailSender не будет совместим со старым, отчасти от того, что пока реализация одна - никто не знает, как лучше всего выделить абстракцию между разными реализациями - это просто невозможно, пока нет 3-4 разных реализации; и даже когда они есть, бывает появляется 5-я и внезапно оказывается, что она сильно отличается и абстракцию надо было выделять совсем иначе. Может быть доп. параметры понадобятся, может быть у него принцип работы другой (асинхронный вместо синхронного, например) и т.п. Так что все равно приходится идти и править вызывающую сторону.

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

поинт про то, что трудно разглядеть API объекта, класс которого используется через интерфейс, легко уничтожается определением публичных методов выше остальных методов

В методе и реализация. Придется искать это самое API среди реализации. Если только там не методы на 20 строк со всеми пробелами и сигнатурой. Не в идеальном мире

cmd+f12 в идее решает все проблемы 🙂

Не спорю. Я к тому, что кто не хочет делать по канонам, найдет всегда контраргумент - оправдание

Совершенно адекватный подход, которого так же придерживаются многие. Можно и так и так

Тут скорее надо с командой общие подходы выработать

как добиться результата, приведенного на диаграмме без интерфейсов ?

Не имеется в виду не использовать интерфейсы вообще

использовать слаботипизированный язык?)

вижу вы читали эту книгу)

В данном случае "Презентатор" (охоспади, ну и перевод) и должен быть интерфейсом. У него же 2 реализации. Зачем добиваться этого без интерфейсов? Тут они как раз нужны.