посмотрите www.youtube.com/watch?v=0cFoEPhv2II&t=1660s
40:50 про скрывание аккардиона на gitlab — будет интересно узнать интересный момент в vue )

что все эти правила преобразования из А в Б могут быть действительно где угодно, размазанные по кодовой базе

Так же, как и ваши DTO которые вы можете складировать куда угодно, называть как угодно, и использовать как угодно. Половину из них вам может быть лень выделять в отдельные DTO, и вы обмажете их атрибутами мапинга — которые все кейсы покрыть не смогут. Это ещё усугубляется моментом, что класс в Java — это не данные, это данные+поведение, в кейсе с DTO мы используем его как дынные, что гарантируется только конвенциями, а не ЯПом.

Тут ещё момент с инстанцированием, код в стиле

var userDto = new UserDto(
  user.getId(),
  user.getName(),
  user.getSome(),
  ....
);

которого в кодовой базе серьёзного проекта просто море — это кошмар.
В тайпскрипте это легко автоматизировать (очень легко).
Это ещё хорошо, если разработчик использует конструкторы для DTO, я встречал подходы в C#, когда все свойства делают с сеттерами, что бы костылить присваивание через рефлексию.

Помимо этого, есть претензии к Optional типу.

В Java нет юнионов, но при разработке они нужны — встроенный тип Optional тому подтверждение — это закостыленный с помощью контрактов юнион, который по сути ничего не гарантирует (да, он даёт варнинг, которых в большом проект могут быть тысячи). И даже если бы он работал как надо — реализация через контракты, это костыль.

Свой аналог типа-объединения без контрактов тоже не получиться сделать — например пытаться эмулировать его наследованием можно, но если он будет содержать дженерики (а кому нужны юнионы без дженериков?) — то он будет страшно неудобен в использовании.

Нет адекватной интерполяции строк.
Вести разработку в чём-то кроме идеи — невозможно, потому что половина проекта работает на кодогенерации

Отсутствие дженериков в рантайме в языке со статической, строгой номинативной типизацией — вызывает кучу вопросов. и добавляет кучу неудобств.

Подход в JPARepository, когда наследуешь интерфейс, пишешь в нём методы, а реализацию за тебя дописывают (я, если честно, не знаю. кто или что это делает) исходя из букв в названии метода — явно не от большого богатства системы типов сделан.

В целом, общая претензия такая — у ЯПа нищая, просто обездоленная система типов, которая не позволяет детально выразить даже самый простой домен.