Sorry, but I disagree. It's not about the "image nature" of CL (which, btw, is a very outdated way of using CL), but the interactive nature of CL. They're similar, in that a Lisp REPL has a memory image, but a running program in any language has a memory image.
Python, Ruby, Haskell, or any language with a REPL can experience this same problem, only in those languages there's not a good way to handle it.
Edit: To expand a little more, the "image nature" of CL has historically referred to dumping the in memory image to disk, quitting, and then loading that image back into memory later when the program starts again, and that's really an orthogonal concept to what TFA is talking about.
Not all programs in every language / implementations have a 'memory image' in RAM or virtual memory. There may also be different types of data. What they usually don't do is to dump and restart those memory regions, like a heap of code and data in something like many Lisp system. Notable exceptions are virtual machines for running operating systems or operating systems with sleep modes, where the whole running OS can be saved to external storage and be restarted.
Some Lisp system don't use images of the heap memory to save and restore programs - examples are some Lisp systems who use external C compilers to compile code to native code and Lisps who run on other software platforms which don't support image (like the JVM).
The other (mostly independent) dimension is that most Lisp systems/program still include development tools like: a read eval print loop, a debugger, a compiler, a code loader (a tool which can load source or compiled code into a running Lisp), possibly more IDE features, debug information, parts of the source code, ...
Many other language implementations have that (or a subset), too: Python, Ruby, ... though often the preferred development style is not to incrementally develop from a long running application which includes the development tools and/or which could talk to an external IDE.
The lifetime of a Lisp program and its IDE can be extended (to weeks/months/years) when it is saved and possibly restarted - thus the *need* to provide tools to integrate program changes increases and this leads to more ways how to update the running program. The Lisp and its program might not be built from scratch for a long time (weeks/months upto years).
If we had only a Lisp system like ABCL on the JVM (which can't save / load memory images, because of the missing support in many (all?) JVMs), there would be less need for incrementally developing with running development system, because there is no way to save the running system to disk -> most programs would often be built from scratch and the program would be started from loading code&data in some way. Features of incremental development might still be there, but not the bigger picture (sic!).
So I would still say that the way a program is developed and built has some influence how dynamic the program will be at runtime and vice versa.
Python, Ruby, Haskell, or any language with a REPL can experience this same problem, only in those languages there's not a good way to handle it.
Edit: To expand a little more, the "image nature" of CL has historically referred to dumping the in memory image to disk, quitting, and then loading that image back into memory later when the program starts again, and that's really an orthogonal concept to what TFA is talking about.