Let me list a few.

* Lisp usually needs garbage collection. There are almost no standards
for garbage collection systems.

* Lisp programs often have a high cons-rate. Thus Lisp usually needs
a very efficient garbage collector to be competitive.

* Lisp has the idea of high dynamisn in the runtime. You can redefine
a function and user code will immediately use the new one. You
can change a class and existing objects will be changed. You
can change an object from one class to another. All this
induces additional redirections.

* Lisp in its standard data types does not care that much about data layout.
This can be inefficient. Various Lisp dialects have special
purpose data structures.

* Lisp has typed objects with identity. Objects carry around their
types (often using low-level tags). This again makes Lisp objects
in their data layout incompatible with most other systems.

* Lisp prefers heap consistency. Usual operations should not
corrupt the heap in the presence of dynamic typing.
This makes it necessary to check operations
before they are applied to objects. Untagged objects are
cannot be checked without knowing their types from somewhere else.

* In the presence of large virtual memory systems, you immediately
need special infrastructure to reduce paging when you deal
with a pointer chasing language like Lisp applied to a
application domain with GBs of memory.

* Lisp has a different surface syntax.

* Support for Functional Programming (Closures, ...) and Object-oriented
Programming is still unusual in the operating systems we use.
Standards are rare (CORBA, .net, ...) and limited.

* CLOS supports meta-level programming, multi-dispatch,
extension of classes, little data hiding - making it mostly
incompatible even in the basic paradigm with most
Object-oriented Languages which are mostly following
some kind of message-sending paradigm.

* No current OS uses Lisp's infrastructure as a model
of organizing memory and/or data. There is no support from
other communities for the Lisp infrastructure.
(Exceptions are systems like Maxima, ...).

* There is little culture of static checks on the code level
(by the compiler etc, ...). So you need to load software into
a Lisp to inspect it or check it.

There is more to mention, but this should be sufficient to list.

The consequences are:

* most OS-level development tools cannot easily or usefully applied
to Lisp code.

* the Lisp ideas about data layout are completely incompatible with OS-level
ideas of data-layout. Lisp has its own ideas about data
and thus needs to implement its own memory and data management.
Almost none of the existing systems bought into that
and tried to use Lisp's infrastructure.

* if Lisp wants to talk to the OS, it needs to use the OS datastructures
or convert those into its own datastructures.

Lisp is not on its own with these 'problems'. Smalltalk, Prolog, Java, ...
also have similar 'problems'.

The combination of these things automatically makes Lisp a very
different infrastructure on any currently used system.

In the 'Lisp World' one should follow a few rules to be successful
with software design:

* the best chance to survive have extensions that follow the spirit
of Lisp (syntax, semantics, ...)

* See the basic Lisp as some kind of abstract machine and build on top.

* when in doubt design software to be dynamic (changeable at any time).

* when in doubt design software to be introspective

* when in doubt design software to be reflective

These rules are very different from what you see in many other software
systems. There, for example, the compiler
will compile it to static, non-reflective, non-evolvable machine code.

It is true that this different nature makes Lisp automatically
a second class citizen on any current OS. But since Lisp is
sufficiently different, its feature set also guarantees its
survival. There are few comparable Languages/systems in
the same niche (with some overlap from Smalltalk and Prolog).