I think it comes down to compile-time optimization and code reuse.
Lisp-like macros let you take code you've written and use it as data during an arbitrary compile-time calculation (which might give you code again), which you have to define. If you also want to use the compiler's own cleverness in your computation, you need another leap of technology, such as hygienic macros or some kind of explicit compiler access within the macro code.
Lambda syntax lets you take code you've written and use it as a function value, with the compilation of that function happening during compile time using the compiler's existing cleverness... and nothing but that.
Quote syntax (as well as fexprs in general) lets you take code you've written use it as data, but it does little to assure you that any of that computation will happen at compile time. If you want some intensive calculation to happen at compile time, you have to do it in a way you know the compiler (as well as any compiler-like functionality you've defined) will be nice enough to constant-propagate and inline for you.
If you don't need compile-time guarantees, then quote syntax is enough. If you're only going to reuse code as code, then lambda syntax may be enough, depending on your definition of code. If you're going to reuse code as non-code (from the compiler's perspective) and you want it compiled anyway, macros are a way to do that.
In the case of Arc, the compile time guarantee advantage is a bit flimsy considering everything's interpreted anyway, but Arc's macro system at least gives a loading time guarantee, which ought to be pretty similar for the purposes of long-running server applications.