No. It makes it easier for parsers. Like that macro you want to write. If you think the hardest part of a compiler is the parser, boy you're in for a shock.
Not even that. It's about making thing easiest for metaprogrammers.
Things most people don't know: C#'s LINQ is extensible in a fashion quite similar to LISP macros (look up expression trees), but the job of processing all of the syntax means that nearly no-one has ever done it.
https://dl.acm.org/citation.cfm?id=2364563
(Caveat: I'm the author of that paper)
Programming frameworks, language extensions (Qt,GWT,..) and their programming conventions are all attempts to build up language towards the problem. Often they would benefit from having parser and compiler, but get buy by relying on programming conventions (object relational mapping frameworks for example) and massive amounts of xml or json configuration files.
Ideally Lisp is like ball of mud - you can throw anything you want into it, and it's still Lisp. You are programmer framework configurator.
Lisp syntax is just a notation for lists. Lisp implementations process those lists.
Any syntax which is a notation for something generic quite much makes sure that most changes into the compiler does not ripple into the parser. They make it easier to experiment with your compiler design because you're not changing parsing rules all the time. And changing parser code tends to be error prone and take lot of time, even when you're using parser generators.