There are several ways to look at lisp macros but I think the most fundamental aspect is that they are hooks that allow one to run code at compile time in a dynamic compilation environment. In other words with lisp macros comes compile-time state. This is a big deal. Imagine the following piece of code:

    (serveMQTT ...)
    (serveMQTT ...)
    (serveMQTT ...)
    (serveMQTTDoc ...)

Compile-time state and a language that is also its own macro-language. That'd be a nice thing to have.

So you might think, but macro-expansion as it is implemented in mainstream Lisp dialects is separate from compilation and isn't informed by compilation.

A form to be compiled is first subject to expansion, and then the expanded result, now devoid of macros is compiled.

Implementations that have multiple modes of processing, such as both a compiler and interpreter, share the macro expander between them.

There is redundancy between macro expansion and compilation. The macro expander has to understand and properly traverse special forms, and build up an environment structure that follow lexical scopes. Then the compiler has to do the same. Of course, the compiler won't have macro content in its environment stacks (lexical macros); those are gone.