Functional programming is not inherently inefficient. There is no reason why the language semantics have to closely match the underlying execution model, although a closer match certainly makes compilation easier.
But FP languages don't have feature those complex semantics, e.g. the ML language family has very enjoyable statically typed imperative-functional languages like OCaml. Aside from having to deal with closures, compiling OCaml is not fundamentally different from compiling C. And C also has problematic features that limit its efficiency on current hardware, e.g. pointer aliasing.
If functional languages have a problematic feature w.r.t. efficient execution, it is the need for garbage collection. E.g. immutable data structures, closures, and continuations all benefit if:
- unreferenced data can be cheaply garbage-collected
- possibly: data can be copied cheaply, e.g. through copy-on-write (CoW)
- an execution model that doesn't assume the existence of a stack
These are things that could in principle be moved into silicon, e.g. a MMU chip with hardware GC, and built-in virtual addressing that supports CoW. (Yes I'm aware of CoW pages, but that isn't granular enough here.) However, that would imply a radically different memory model than is used today. I doubt this would be more efficient than the current state of the art, but it might allow more efficient execution of functional and object-oriented programs than on current hardware.
But that is not going to happen, simply because economies of scale favour the status quo. Once upon a time there was functional-programming hardware: Lisp Machines. Those pretty much died out, because of declining Lisp demand, and because of microprocessors (like x86 chips): Microprocessors are already fast enough. Building great compilers is cheaper than developing competitive chips. For similar reasons, hardware JVMs never really caught (although Java platforms certainly did, see Android and many feature phones).