If you absolutely, really need @Data, why not consider making your fields public? I mean, if the only access semantic is going to be exactly the same as public field why have getters and setters in the first place? It just seems dumb to me and not how Java language was designed in the first place. For me it is trying to fix problems of one bad pattern with another bad pattern (now you have two problems).

Readability depends on how large work you do and how much experience you have. Readability is not just how much code you have, it is about using consistent patterns to solve your problems. Readability is how fast and how safely you can move around the code to understand how it works at any level of complexity.

I have 17 years of experience working with Java commercially.

I am blind to getters, setters, builders, and bunch of other stuff. It does not bother me, I can recognize patterns immediately and just ignore them.

What bothers me is when I don't trust my IDE to find all uses of something because some jackass decided to add Lombok to the project and now my IDE does see all code exactly as it will be running.

This is much more of a readability fail.

When you make global refactorings on an application that has over a million lines of code it is absolutely crucial you can trust your IDE to find all uses of something.

This is true as the point of getters and setters is encapsulation, if you totally ignore it there is no real reason to have them at all and public access is a language feature to use.