It is always a matter of ROI, how far one is willing to invest, money and time, in a compiler/interpreter/JIT implementation for the use cases a language is targeted for.
As for the current state of native compilers for dynamic languages, they suffer from the fact that past the Smalltalk/Lisp Machines days, very little focus has given to them in the industry.
Hence little money for research, while optimizing compilers for static typed languages where getting improved.
Dylan was the last dynamic language with a AOT compiler targeted to the industry as system programming language, before being canceled by Apple.
If it wasn't for the JavaScript JIT wars, probably the situation of compilers for dynamic languages would be much worse.
Lisp Machines never had sophisticated compilers. The compilers for the Lisp Machines were primitive in their capabilities. The compiled to a mostly stack architecture, where some speed was recovered in hardware from generic instructions. The work on better compilers for Lisp came most from other places: CMU for their Unix-based CMUCL, Franz with Allegro CL, Harlequin with LispWorks, Lucid had a very good compiler with Lucid CL, Dylan at Apple for early ARM, CLICC in Germany, SBCL as a clean up of CMUCL, Scieneer CL as a multi-core version of CMUCL, mocl as a version of CLICC for iOS/Android, ... plus a few special purpose compilers...
Once you add sophisticated compilation, dynamic languages implementations are no longer 'dynamic'.
This topic is pretty much solved for Lisp. On one extreme we have fully dynamic interpreters + then dynamic AOT compiler based ones. For delivery there are static delivery modes available (for example with treeshakers as in LispWorks).
On the extreme side you get full program compilers like Stalin (for a subset of Scheme) or like mocl (a recent compiler for a static subset of Common Lisp, for iOS and Android).
"It is always a matter of ROI, how far one is willing to invest, money and time, in a compiler/interpreter/JIT implementation for the use cases a language is targeted for."
That's just a long way of agreeing with me. If one language can require a great deal more effort than another to run quickly (and I'm not assuming the slow language even makes it to the fast language's speed here), then it is therefore the case that languages designs do impact the experienced run time performance. That's the entire point.
And given where the plateau on the dynamic languages seems to be getting drawn, I see no reason to even hope that a dynamic language will ever run as fast as C in general. They are plateauing way too high for that to be the case, probably even with infinite investment on current hardware.
As for the current state of native compilers for dynamic languages, they suffer from the fact that past the Smalltalk/Lisp Machines days, very little focus has given to them in the industry.
Hence little money for research, while optimizing compilers for static typed languages where getting improved.
Dylan was the last dynamic language with a AOT compiler targeted to the industry as system programming language, before being canceled by Apple.
If it wasn't for the JavaScript JIT wars, probably the situation of compilers for dynamic languages would be much worse.