тогда противопоказаний по использованию уже нет?

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

а меня больше интересует другой вопрос — если ломбок это круто, избавляет людей от кучи бойлерплейта — почему бы не добавить это всё в базовую комплектацию, чтобы из коробки всё работало?

я бы ответил так ломбоко — это как приправа в суп. кто то любит по острее (все  хардом написано) а кому то по ароматнее (без геттеров например)

Кажется, вы изобрели котлин! :)

на одном докладе про это касались,  "мы тут @NotNull Ждем уже пятнадцать лет, а вы предлагаете вашу кастомную анотацию внести в stdlib"

я не спорю, я только спрашиваю есть ли подводные камни, которые не видны сразу?

интеграция с другими либами, которые тоже процессят аннотации

а так в меру если - удобно

так все ведь тюнится анотациями. любая приправа)

плюс не все проекты на современной джаве последней версии

чето я не удивлен что Котлин упомянули =)

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

На Joker'е отдельная лекция была на тему, насколько хитрожопа может оказаться вроде бы вполне понятная аннотация. Большая часть примеров была, конечно, как абстрактный сферический конь в вакууме, но часть вполне себе жизненна

нафига что то еще "подтачивать" особенно  что то из натаций, будет самописный велик так что ли?

Хуелик.
Типа, писать код плохо, самописное == говно? Тогда лучше не прогать вообще.

есть. c capitalized проперти бывают траблы. то с чем сталкивался. пример:
1.  нужно отправить json в сервис, в DTO проперти в uppercase. типа BP_USER_ID, BP_SESSION_ID... ломбок их сделает (по дефолту) bp_USER_ID, bp_SESSION_ID
2. тоже самое с маппингами entity в jpa. если сложное название поля типа rPersAccountId могут быть траблы. jpa потом не поймет

это если из коробки юзать, как есть. все решаемо. все равно профит от использования lombok тем больше, чем больше проект

не тот посыл — писать твои боинги а мелочь брать стандартную или по малому говнокодить если "душа" просит — главная мысль — все в мире по мелочи написано есть и гайки и болты

Гайки и болты есть, а вот состав сплава и геометрия граней не всегда устраивает :)