Reality has a strong imperative bias, where "LISP Machines" would actually run imperative code faster than LISP itself, because
the hardware is serial and imperative due architecture and merely has additional blocks to speed up LISP construct execution.
True LISP-centric architecture has never actually been tried,
IMHO as a C programmer, the pervasive use of lists as data clashes with dumb storage memory optimized for throughput:
LISP machines don't fix this, they're basically same dumb memory with extra bits to indicate some type/state, tasks were just offloaded to CPU.
What is actually needed is 'content addressable memory' Field Encoded Words (see https://en.wikipedia.org/wiki/Content-addressable_memory#cite_note-WisePowers-5 ) where such "Database Operations" are List Processing directives(i.e. core primitives).
It was used for Prolog, but imagine its being adapted to LISP - the memory itself of course being same as LISP machine tagged architecture memory.
``An alternative approach to implementation is based on Superimposed Code Words or Field Encoded Words which are used for more efficient database operations, information retrieval and logic programming, with hardware implementations based on both RAM and head-monitoring disk technology.[5][6]``