I suppose it's a bit of 1 or 2 or 3. But there's also the issue that emergent properties which fall out of the overall design are quite hard to explain, and even advanced students of the subject don't fully grok yet.
For example, "code is data" is true in the most trivial sense for machine code, yet having code as structured data makes it much easier to manipulate. Having easy to manipulate code gives you the power to manipulate code at compile-time. Having code run at compile time inside the compiler, which is also an interpreter running the same language that you are compiling is kind of magical and mind-bending.
In fact, more recent research into this has gone down the rabbit hole even deeper, and it turns out you can have an entire tower of meta-levels (see for example http://www.phyast.pitt.edu/~micheles/scheme/scheme22.html). This is all continuing on the same basic ideas which were present in early Lisps, just crystallized and refined further and further.
Also, as research into macros has gone on over the years, hygienic macros were discovered, which Rust has adopted as well (and there are other languages which have them as an add-on, like Sweet.js). Deeply understanding how this stuff works gives you a better grip on the issues with macros in older languages (notably C).
And that's just macros (and homoiconicity). There's also lexical versus dynamic scoping. This is a lot less "magical" now than it was 10 years ago, when almost no mainstream language even had closures.
And, oh yeah, grokking continuations makes it a lot clearer how generators, iterators, exceptions and coroutines work. One concept which subsumes all the others. And if you want to get into compiler construction, understanding CPS conversion makes it much easier to do code transformations.
There's just tons of research which went into Lisps, because it's such a nice vehicle for language experimentation. There's half a century of research going into Lisps. Other languages haven't been around for that long, so I suppose there's something to find in Lisp history for everyone, but it might not be the same thing for everyone!
> Are Rust macros at all comparable to Lisp macros?
There are two major kinds of macros in Rust. One of them, macro_rules, is vaguely similar to Lisp macros. It was partially designed and implemented by some big Racket fans, in my understanding.
> Can you re-write the syntax of Rust with Rust macros?
Within limits.
> Or are they more like C/C++ macros?
Neither kind of Rust macros are like C or C++'s macros.
For example, "code is data" is true in the most trivial sense for machine code, yet having code as structured data makes it much easier to manipulate. Having easy to manipulate code gives you the power to manipulate code at compile-time. Having code run at compile time inside the compiler, which is also an interpreter running the same language that you are compiling is kind of magical and mind-bending.
In fact, more recent research into this has gone down the rabbit hole even deeper, and it turns out you can have an entire tower of meta-levels (see for example http://www.phyast.pitt.edu/~micheles/scheme/scheme22.html). This is all continuing on the same basic ideas which were present in early Lisps, just crystallized and refined further and further.
Also, as research into macros has gone on over the years, hygienic macros were discovered, which Rust has adopted as well (and there are other languages which have them as an add-on, like Sweet.js). Deeply understanding how this stuff works gives you a better grip on the issues with macros in older languages (notably C).
And that's just macros (and homoiconicity). There's also lexical versus dynamic scoping. This is a lot less "magical" now than it was 10 years ago, when almost no mainstream language even had closures.