Agreed that it _can_ make code challenging to understand.
However, the engineer in me thinks that this is not a linguistic deficit, but rather illustrates poor judgement and taste on the part of the implementors. The litmus test of 'can this be expressed as a function?' will usually suffice for determining whether or not macros are being abused. Under this rule, debugging macros is no harder than debugging "normal" code.
Of course, people will disagree with me regarding poor taste, offering something that boils down to "if everyone using a tool is doing something poorly, then surely the tool is to blame." The problem is (1) that obviously isn't true as it boils down to a fundamental lack of skill and (2) in this case, there are numerous examples on the web of good use of macros that make code easier to understand. Tools themselves are casually inert and deserve no blame for the outcome of their uses as directed by the will of a separate entity, i.e. the programmer.
Judicious (read: professional) usage of macros will only ever make code easier to understand. If a macro is obfuscating meaning, then the macro has been used poorly. Luckily, a few books (LOL) have numerous examples of tastefully done macros. Lots of Clojure libraries have also shown what macros can do.
TL;DR: we're free to write good code, we're free to write bad code.