If you're going to do SIMD, you have to care about memory alignment. If you're going to do high-performance without SIMD, you still wind up caring about things like cache misses. So you'd want a Lisp that 1) lets you control memory alignment, and probably 2) that doesn't garbage collect. At that point, is it really a Lisp?

Now, you may say that "performance-oriented" doesn't have to go as far as SIMD or caching tweaks. And that's true. But if you want a performance-oriented language that can reach all the way up the performance curve, I don't see it being Lisp.

Depends on which parts of Lisp you're interested in. You can go as far as writing Lispy assembly (SBCL does), which gives you control over memory and is not garbage collected.

As someone desiring a performance-oriented Lisp, this is something I'd like. At runtime, I can handle memory myself ($deity knows I often do that when writing performant code). What I want to have is the friendly, homoiconic Lispy syntax, the ability (and the ease) to write code that writes code, and perhaps to have these facilities available at runtime.

Also, memory alignment isn't an entirely foreign concept to Lisp, it just rarely has been a focus. The long living irony that the etymology of the names of very common Lisp functions `car` and `cdr` themselves are a lingering artifact of 36-bit word memory alignment on an ancient IBM system architecture.