Lisp macros are still just code, code that executes at compile time instead of run time. Code generated in response to an Java annotation is only loosely associated with the annotation itself.

Annotation Oriented Programming arose out of Java's lack of powerful and general abstractions like first class functions. Lambda syntax for "single abstract method" interfaces has largely addressed that problem, but the use of annotations as the primary higher order abstraction mechanism remains in Spring and similar frameworks.

Lisp macros are part of the day to day tool set of every day Lisp programmers. They should be used with restraint, but can be debugged and analyzed with the same development tools and skill sets as other Lisp code. Java annotations belong much more firmly in the realm of framework authors. Writing Java applications often involves using annotations, but very rarely involves creating annotation and generating code or new behavior based on them.

> debugging is more complicated

Only if macros are second-class relative to built-in primitives in terms of debug support.

E.g. typical C compiler and debugger not knowing anything about C macros; if we make a loop construct entirely in a C LOOP(...) macro (spanning many lines of the source file), any error within the statements and expressions enclosed in LOOP will be reported against LOOP's line number. Moreover, we will not be able to step through those individual expressions in the debugger.