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

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

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

Тут на 100% как с sql - если ты sql используешь - то кто ты - конечный пользователь субд или программист?
В этой аналогии - если аннотации используешь - значит ты конечный пользователь, не имеющий права ломать систему.
А когда ты программист, и пишешь код, реализующий содержательные алгоритмы, то места для аннотаций в нем непосредственно,
скорее не будет.
Код либо есть и представлен явно, либо его нет по причине посадки в чёрный ящик аннотаций - он становится технически
ненаблюдаем, и тогда судить о нём возможно только с применением продвинутых экспериментальных методов английских ученых...

суть дела в том, что ты ни коем случае не должен над этим задумываться.
Задумался - пропал, сломал концепцию, занялся тем, что не является твоим делом, то есть - занялся прямым саботажем и вредительством.

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

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


А у "увеличения понятности языка" со временем есть объективные причины, на которые указал Страуструп в недавно обсуждавшемся интервью - игрушечный язык может быть простой, но при расширении области его применения он объективно становится сложным, вслед за желанием решать более сложные задачи.
Правда, методом применения массового коллективного образования можно получить сложный язык и без увеличения сложности решаемых задач.

все образование вообще строится на простом когнитивном искажении.
И оно не может быть не элитарным...

Спросите об этом Ноама Хомского - он больше всех об этом знает, а популярно даже Юваль Ной Харари сможет объяснить
:)

имхо, стратегически - вся. Программист не должен догадываться, почему его код вообще работает.

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

Недостаток ООП состоит в том, что у тебя остаются концы, потянув за которые, ты сможешь решить - работает ли программа вообще и
в чьем коде содержится проявившаяся ошибка.

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

Думаю, последний тезис не на 100% верен, но до определенной степени так и есть.
Здесь все-таки предполагается, что должен быть набор людей, через которых осуществляется контроль над самими "промышленными инструментами" - и у них должно быть другое образование.

Сейчас уже практически пришла пора, когда людям можно платить просто за то, чтобы они ничего не делали, совсем ничего,
но не возмущали при этом общественного спокойствия.
(У Бредбери пожарный на всякий случай сжигал книги в домах людей, чтобы те не выбивались из рамок ООП и прочего текущего образования для всех. Имени этого пожарного появился HTTP код 451)

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

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

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

Эта, да - сила....
Никто не знает как они работают.
Просто они так научились работать, вот и всё.

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

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

С другой стороны, собственно код становится предельно компактным и бессодержательным.
Use old plain java object, Luke.
Только не забудь поставить правильную аннотацию. Тогда твой object внезапно оживет и шикарно отработает.