Don't be fooled by a legion of old-time lispers. Macros are a last resort in real-life Lisp (aka Clojure).
Hard to write (way harder than a function), hard to debug, hard to reason about, they're not functions (so fit worse in the rest of the language)... but powerful when you really need them.
"When you have a hammer...", and a desire to stand out from other languages made the lisp-macro myth flourish.
Well actually, in a modern lisp (like Racket), you use macros in a variety of ways.
In addition to "deep" things, often you use them as practical, simple alternatives to using stuff like "snippets" or heavy IDEs. You can "DRY" annoying patterns, without resorting to external tooling.
Although macros used badly can be mysterious, so can any excessive pre-processing and build magic.
Macros provide "an API for the compiler", and since the compiler is involved, it can be smarter than external tools.
As I said, when you really need them they're useful (e.g. in typed Clojure). Most (if not all) DRY patterns can be fixed using only functions.
The problem is, the macro mantra has been parroted for so long now it's part of the Lisp culture and its external image ("Lisp is homoiconic! You can modify code! Macros! MACROS!"), when it's actually one of the ugly (but powerful) parts of Lisp you should avoid most of the time. This confuses beginners and people interested in Lisp.
I see macros fitting mainly in DSLs (which is probably a code smell most of the time) and extending the language, as typed Clojure does. What other real use cases do you see for macros?
The real use cases for macros boil down to 3 main areas:
1. Changing order of evaluation.
2. Creating new binding forms.
3. Implementing a data sub-language a.k.a. DSL
Although arguably #3 doesn't require macros, arguably it requires macros to do elegantly (Rubyists might argue not) and reliably (instead of monkey-patching, using hygiene and a macro-aware module system that can handle towers/layers of such systems).
Well, 1 and 2 are the only cases where they are absolutely required, but I've seen other use cases. For example, the ClojureScript templating library Dommy uses macros to optimize selector code at compile time, which gives some impressive speedups (IIRC Prismatic found it to be twice the speed of jQuery).
Modern Lispers (and modern Lisp learners' resources such as Seibel's Practical Common Lisp) talk about macros in exactly this fashion. I'd be willing to argue that the lesson has been learned.
There are many more real-life Lisp applications which are not written in Clojure.
I'm a long-time user of Scheme and especially Common Lisp. Macros are a consequence of Lisp. Lisp is originally about computation with symbolic expressions (see McCarthy). Application of that to Lisp itself leads to macros and similar. Macros were introduced 1963 to Lisp, extremely early on.
As a Lisp programmer one needs to understand what macros are for and when they are useful. By default I write functions. I also tell people to think in functions first.
But in real life, the more advanced Lisp applications are full of macro usage and macro definitions.
Sure they are harder to debug. But Lisp programmers have developed tools to deal with that. Not everyone wants to learn such a complex language, or is able to learn it or has time to learn it. There are a lot of simpler tools and even simpler Lisps - but for those who want and need this, a language like Common Lisp will provide the necessary flexibility.
Hard to write (way harder than a function), hard to debug, hard to reason about, they're not functions (so fit worse in the rest of the language)... but powerful when you really need them.
"When you have a hammer...", and a desire to stand out from other languages made the lisp-macro myth flourish.