You're mostly mistaken, and you've mostly been fooled by changing names.
Clojure lists aren't lazy, and they support the Lisp operations, under slightly different names, and with the same asymptotic performance characteristics you're used to, because they're made of chained cons cells. The cons operation is implemented at https://github.com/clojure/clojure/blob/master/src/jvm/cloju.... Your "more complex example" is a 1960 program written, originally, in M-expressions; here's the first definition on the cited p.32:
th1r[v;a1;a2;c1;c2] = [atom[v] → member[v;a1]∨
th[a1;a2;cons[v;c1];c2];T → member[v;a2]∨
th[a1;a2;c1;cons[v;c2]]]
As far as I know, there hasn't ever been a Lisp system that could parse and run that, and certainly not LispWorks. But you can straightforwardly transliterate it either into Lisp 1.5, or Common Lisp (although the post you link doesn't bother; instead they wrote an interpreter for the incompatible Lisp 1.5 syntax in Common Lisp), or into Clojure:
(defn th1r [v a1 a2 c1 c2]
(cond (symbol? v) (or (some #{v} a1) (th a1 a2 (cons v c1) c2))
true (or (some #{v} a2} (th a1 a2 c1 (cons v c2)))))
The only weird thing here is using the set-membership test instead of MEMBER.
Compare the above to the LISP 1.5 version:
(TH1R (LAMBDA (V A1 A2 C1 C2) (COND
((ATOM V) (OR (MEMBER V A1)
(TH A1 A2 (CONS V C1) C2) ))
(T (OR (MEMBER V A2) (TH A1 A2 C1 (CONS V C2))))
)))
Clearly Lisp changed a lot between LISP 1.5 in 1962 and CLtL in 1984, not to mention current Common Lisp practice; what you'd write in any modern Lisp looks a lot more like the Clojure version than the LISP 1.5 version.
The set thing, though, points to a real difference in Clojure: it has a set data type, and you're expected to use it instead of the list data type when what you want is a set. It's still immutable, though, and supports efficient nondestructive update, so if you decide to rewrite this as
(defn th1r [v a1 a2 c1 c2]
(if (symbol? v)
(or (a1 v) (th a1 a2 (conj c1 v) c2))
(or (a2 v) (th a1 a2 c1 (conj c2 v)))))
you can be assured that you're not totally hosing your program's performance. It might get better, in fact, if the sets are large.
You could argue that adding sets (and finite maps) to Lisp is violating the underlying essence of Lisp, in which you use conses for everything, but in fact we already have vectors, hash tables, classes, structs, and closures in all of the other Lisps you're citing, none of which were present in the Ur-Lisp in 1960.
ATOM doesn't exist in Clojure, although you can define it. atom does, and yes, it does something totally different from what ATOM did historically.
By "persistent" Clojure means "immutable". That is, there's no RPLACA or RPLACD. But RPLACA and RPLACD weren't present in McCarthy's original proposal, and they're hardly central to Lispiness. You could even argue that their absence is Lispier, since it encourages functional programming and enables the compiler to optimize it better, and indeed Racket already abandoned them a few years back for that reason.
BTW, I was wrong about what you would have had to type at LISP 1.5's read-apply-print-loop. You would have had to type
CAR ((QUOTE (1 2)))
for obvious reasons.