Forgive my ignorance, but what should it be doing instead?

Lombok is a very divisive framework in Java, with strong opinions on both sides.

Given that, it's a bold choice to include Lombok in a library that other developers will pull into their stack - it's likely to make this a non-starter from those in the 'no' camp.

As Lombok is just compiler sugar, when building an SDK for other developers, it's probably less alienating to just write the boilerplate that Lombok saves you from.

Lombok is a compile-time dependency. Consumers of a library using lombok don't need to depend on lombok, so I don't see why it would matter?

The symbols remain in the final library, necessitating either class exclusions within the scope of a JAR you don't control (which is a terrible idea) or the addition of a dependency which is irrelevant, inert, and has no place in your codebase.

It is embarrassing for a library to ship ABI-visible symbols from Lombok.