Чет боюсь рефлексия относится к lombok таким же образом как и спринг к особенностям конкретного сериализатора, т.е. никак.

Прямо откровение за откровением можно сказать... По ссылке что вы привели происходит следующее: два имбецила впихивают бизнес-логику в POJO и удивляются чего это оно работает не так как ожидается - так делать не нужно, потому то есть более правильные способы, это раз. Если попытаться разобраться в "проблеме" более глубже, то можно найти например такое обсуждение: https://github.com/FasterXML/jackson-databind/issues/1239, суть его примерно в следующем: в джексоне этих аннотаций для поддержки десериализации понакручено столько, что толком разобраться в том что происходит при включении тех или иных модулей и/или смене версий вообще невозможно, вывод отсюда такой: не нужно ничего накручивать вообще, а чем проще тем лучше. Lombok к поведению джексона здесь вообще никаким образом: они добавили java.beans.ConstructorProperties в далеком 2010 году, потому что в то время вообще не было никакой возможности узнать имена параметров к конструктора (java.lang.reflect.Executable#getParameters появился только в 1.8)

Spring ко всему этому имеет единственное отношение: имбецилы из бута (привет Стасу) зачем-то тащат lombok (у которого scope вообще должен быть provided) в spring-boot-dependencies, а хомячки радостно этот spring-boot-dependencies себе в проекты импортируют, как итог при смене версии бута еще и байткод начинает другой генерироваться.

О чем речь-то? Вы утверждали что lombok ломает все и вся и имеет кучу проблем, а как выяснилось это не то что не совсем так, а даже совсем не так, ну и виртуозно им владеть совсем не нужно уметь, вон разработчики из бута мавеном пользоваться не умеет, а что-то при этом разрабатывают. Теперь вы решили переобуться и мы узнаем, что ну раз уж lombok не вредный, то он уж 100% бесполезный, иначе никак. А вот теперь вопрос: зачем мне на code review заниматься фигней и прорываться через портянки кода в надежде определить правильно там equals и hashCode реализованы или нет? или все ли там в конструкторы добавлено или нет? зачем мне вообще лишний код видеть?

потому что ты не особо в теме: чтобы генерить код lombok использует "дыры" в javac, потому что по жавской конвенции AnnotationProcessor не должен гадить в генерируемый байткод, а должен складывать результат своей работы куда-то в другое место, т.е. с компиляторами отличными от javac lombok не работает, а это в свою очередь означает, что, например, полноценно с AspectJ работать оно не будет, точнее post compile time weaving работать может и будет (тут со средой разработки еще придется заморочиться), но вот inter-type declarations уже гарантированно отвалятся.

У вас отношение к кодогенерации несколько превратное. Вот для меня кодогеренация, это когда у нас есть "нечто", написанное на каком-то DSL, мы вызываем mvn compile и на выходе у нас это же самое "нечто", но уже на другом DSL, а вот регулярное выполнение одной и той же последовательности каких-то действий в IDE - это не кодогенерация, а онанизм, как пример: мы можем один XML преобразовать в другой посредством применения регулярных выражений, а можем написать XSLT, в этом случае второй подход, очевидно, более качественный (я встречался с проектами, где бины по XSD/WSDL/YAML генерировали средой и сгененированный результат пихали прямо в СКВ - душераздирающее зрелище). То что вам что-то умеет генерировать среда - это никакой не контракт, и никто не гарантирует что все разработчики в команде будут выполнять одни и те же действия в одной и той же последовательности: завтра кто-то забьет и просрет конвенцию на is/get в случае boolean/Boolean, после завтра кто-то потеряет поля в equals и hashCode, а через день прилетит ПР исправляющий предыдущие косяки, в котором черт ногу сломит из-за тонны однотипного кода. Вопрос: зачем это все мне, когда есть 5 наиболее распространенных аннотаций, которые снимают кучу головной боли?