Lisp

The real problem with Lisp is that it was designed without any consideration of the cognitive load experienced by the programmer.  The syntax may be simple, but the semantics are extremely complex and hard to master.  This is completely at odds with needs of the programmer. 

The main cognitive load is in developing a solution to the real world problem.  The programmer is engaged in reflective cognition.  Basic UI principles dictate that, when designing tools to aid in reflective cognition, they must as intellectually shallow as possible.  The less cognition required to operate them, the more is available for completing the required task.

Lisp was unintentionally designed for experiential cognition.  It contains many artifacts, each with a very deep and rich set of semantics.  All cognition must be devoted to its operation.  It is no surprise that it only attracts programmers who are only interested in using it for its own sake.

>>10
``Languages'' are not performant, fast, whatever, implementations are. Saying ``language A faster than B that is as fast as C'' is meaningless. Even if the language standard library mandates Bogosort as sorting algorithm, it doesn't make the language should. Or, would you say ``Chinese is faster than English because it's more compact and fits better in the brain's L1 cache''?
Maybe you forgot what programming languages are about: abstraction, automatization. Helping the programmer to abstract things away, to help him concentrate only on the problem at hand without having to think of memory (de|a)llocation, pointers, which instruction would be the faster, which instruction encoding would be the smaller. Helping the programmer to automatize the process of writing code such that you'll never need to write the same code twice.
Leave optimizations to the compiler, they exist to automatize and abstract the processes of optimization and translating higher-level languages to assembly. The best you can do is to choose a better algorithm.