Racket's macro system and Kernel's fexprs are pretty fundamentally different, so I don't think the comparison is very apt. In particular, Racket's macros can be entirely compiled away.
While true, I was comparing macro APIs from a usability perspective and should have avoided the term 'abstract model'.
My point was the mental model I refer to when using $lambda is simpler and easier to understand than my mental model for syntax-case, syntax-rules, syntax-parse and friends. The very fact that 'Racket's macros can be entirely compiled away' complicates my mental model which must now accommodate 'phases', compile-time/run-time dichotomies, require for-syntax, etc.
To clarify a little bit, `syntax-parse` is actually not its own model for macros but is a sophisticated front-end for Racket's underlying macro system (described in this paper: http://www.cs.utah.edu/plt/publications/jfp12-draft-fcdf.pdf). Also see Jay McCarthy's blog article that tries to clarify this: http://jeapostrophe.github.io/2013-07-22-123list-post.html
Racket's macro system and Kernel's fexprs are pretty fundamentally different, so I don't think the comparison is very apt. In particular, Racket's macros can be entirely compiled away.