For a language like Lisp, there's argably little difference (Lisp is dead-simple to parse) though it's definitely less of a hassle to work on the parsed tree. For a language like perl, macros would be a very nice thing since parsing perl correctly is a profoundly non-trivial exercise.

Macros and source filters both have their place. It's just a different place...

In Perl, one can modify the program after the parser as well, with the help of the B::* class of modules, and from within a CHECK block.

Abigail

As Elian says lisp macros act on the parsed representation of the code. Lisp code is trivial to parse. It is also made up of simple, fundamental lisp data structures. The power of lisp comes from its ability to trivially represent lisp programs as lisp data. This allows you to write programs which write programs, which is very powerful.

Suppose your language lacked a for loop (as in C and perl) but had a while loop. In lisp it would be very easy to implement one as a macro. This macro for loop would be just as efficient as if the language provided one in the first place. This is a fairly trivial example but it might give you an idea. In most languages you just can't do that. Essentially this gives you a 'programmable programming language' (to quote Paul Graham). It lets you extend lisp into a domain specific programming language for whatever domain you want with no loss of speed. A lisp programmer would not tend to use XSLT for transforming XML - they would just extend lisp to implement the same functionality.

Extending perl in this way with source filters (adding bits to the language) would not be easy due to the difficulty in parsing perl. It is possible that the B:: modules could be used to do a similar thing in perl. I'm not sure though. It wouldn't be easy due to the complexity of the parsed perl programs. Interesting thought though.

Well, if by "one" you mean you, or me, or a very small handful of other people, sure. We can do the same with XS, too--it's still far less safe than Lisp macros, and a bare step above pack "p" and slamming bits directly into memory. It is, however, acting on the final internal representation of the program, rather than on the parsed version of the program. (Though in perl's case there is no actual difference, as there's no 'just parsed' version to manipulate before it gets turned into the structures that get executed)

Could some one give me the 50,000 ft overview of why Lisp macros are easier/stronger/faster/better?

You might find Macros, LFSPs and LFMs and Pretending to be lisp: macros of interest.