I think that saying it's an inherent conflict is overstating it. I think it's a bit more like there are these two axes, a performance axis and a malleability axis, and they aren't completely orthogonal, but they also aren't diametrically opposed.
Granted, if you ignore one axis and optimize the heck out of the other one, you're unlikely to end up in an optimal region of the ignored axis. But there are optimization paths that move in good directions on both axes at once, until you reach some limit where you sort of move around on some boundary arc by trading off one against the other.
Apple's Dylan project was conceived with the explicit purpose of developing a language and runtime that would satisfy the highly-interactive-programming enthusiasts (that is, the Smalltalkers and Lispers) in Apple's ATG and other researchy groups, while also producing built artifacts that were fast and interop-friendly and compact enough that they wouldn't all have to be rewritten from scratch in C, Pascal, or assembly before the product groups would agree to ship them.
The Dylan team did a pretty good job. I was one of their internal customers, working on an experimental handheld OS written mostly in Dylan.
The Dylan team gave us a modified version of Macintosh Common Lisp, called Leibniz, with Dylan support. Leibniz was just MCL, but with a Dylan compiler, object system, and runtime built into it. The Dylan compiler cross-compiled to the handheld's hardware. Our dev machines were Macs, either with daughterboards stuck into nubus slots, or with actual handheld hardware ribbon-cabled to the nubus.
Leibniz had a second version of everything in the MCL environment: there were the normal Lisp listener windows, but also Dylan listener windows. There were normal Lisp editor windows and Dylan editor windows. And so on.
Code compiled and evaluated in the Lisp windows ran on the Mac hardware. Code compiled and evaluated in the Dylan windows ran on the handheld hardware.
Our built software ran on the same handheld hardware as the C++ OS. It performed well--well enough to make some of the C++ team curious sometimes about how we did certain things.
The relevant point is that you can make a highly-interactive and malleable language and development environment that also delivers fast, compact artifacts. I don't think there's an irresolvable tension between those two goals.
On the other hand, optimizing toward both goals is more work than optimizing one at the expense of the other. If you elevate one goal above the other, the elevated goal will benefit and the other will suffer. Optimizing both means paying attention to both all the time, and that sometimes means that you will disqualify certain options. Optimizing both shrinks the workable solution space, so you have to look harder and sometimes solve problems in less easy ways than you would if you were thinking only about the one goal.
On top of that, the features that make an environment a great, malleable, highly-interactive environment are extra. You still have to do all the same kind of work that you need if you don't care about making a highly-interactive environment--lexers, parsers, compilers, optimizers, linkers, editors, indexers, and so on, and so forth--but on top of that, you have to design and build all of the features that make an environment highly interactive--a repl that has visibility into everything in the runtime as it runs, error handling that can spin up an interactive session in the dynamic context of a signaled error, runtime facilities that detect and keep track of every dependency that changes dynamically and knows what to do about it, inspectors that know how to expose and edit every element of state in the whole system, and so on.
That's really the obstacle, I think: a really malleable environment is just a lot more work. That, and to build one you need builders who know what they are and how to build them.