Taking a code base and expanding the macros to see whether that is more or less readable is a bit like expanding a C++ class hierarchy into assembly language and concluding that this program’s object oriented design is great because it is more readable than the resulting assembly language.
The real question is whether or not there are better alternatives than macros or metaprogramming in the first place. Functions, especially as found in modern languages[1], have proven to be very useful abstraction mechanisms and can often mitigate the lack of fancy macros.
I don’t want macros banned from Lisp, but I don’t miss them in other programming languages. Over exuberant use of fancy macros in Knuth’s brilliant TeX, in my opinion, contributes to the glacial pace of LaTeX development.
[1] By this I mean functions with circumscribed access to non local variables, provisions for choices of ownership of parameters, static scoping, first class functions, closures, and recursion.
You're stuck with the ill-designed crap that Python puts out. For instance, I don't agree with pattern matching that assigns to existing variables; from where I'm sitting, it looks like an incompetent clusterfuck. If someone did that in one Lisp program, the entire language would be blamed for allowing that sort of "curse".
The only relevant "better" in this debate is whether that would be more readable in those specific cases. People still make macros over functional solutions; e.g. the trick where a macro expands into just a function call to one or more generated lambdas which hold argument material. All macros expand to nothing but functions and special forms.
TeX macros are just preprocessor cruft that is more closely related to C macros than Lisp macros. TeX and LaTeX are fragile mainly because of the semantically impoverished target language which just has global variables and conditionals. LaTeX macros are leaky; use them in the wrong place and they misbehave.