read と eval が別関数で、
言ってみれば構文木を first class object として扱えるところかなあ。
他の言語の eval だと大抵受け取るのがパース前の文字列なんで、
それを使ってごにょごにょしようとした場合構文木をいじるんじゃなくて
文字列・ソースコードをいじることになるのが面倒くさい。
マクロも同じで、文字列→文字列変換だと、無いよりはいいかもしれないけれど、
lisp のマクロと比べてあんまり魅力的ではない。

まあ、そこはどうにか構文木を直に触れるようになったとしても、
構文木オブジェクト周りで内部表現と外部表現が齟齬をきたす可能性が高い気がする。
つまりソースコードを read して print したら何が表示されるか、
という話で、lisp であるなら元の S 式が表示されるわけだけれど。
そこで表示されるのは構文木の外部表現なのか、元のソースコードなのか。
或いは構文木を write して read したらどうなるのか。
そこで read/write Invariance は保障するのは S 式を採用しないと結構面倒そう。

個人的には read と eval が分かれていて、
read/write Invariance が保障されるなら別にリストじゃなくてもいいかなあとは思う。
ただ、せっかく手軽に切ったり貼ったりできるのにリストじゃなくする理由もあんまりない気がする。
リストって言うか cons,car,cdr で弄れる対象と言った方がいいか。
内部的に対になったメモリ領域じゃなくて匿名関数でもいいけれど、
そりゃ効率が悪い、という話でしかない。
措いてしかし、構文木の内部表現がベクタで、なおかつそれをいじることを前提とした言語であったら、
ベクタを弄り回すライブラリが充実していることだろうから、あまり問題にならないかもしれない。

scheme の syntax-rules みたいなパターンマッチベースのマクロだったら
それなりに他の言語でも上手くいく可能性はあるかもなあと思わなくもないけれど。
少なくとも symbol 型のデータ型は必要になるんじゃないかなあ。
識別子が first class object じゃないと困るって言うか。