A quarter century ago I devised similar machinery for Allegro. It's still in the implementation, and I use it daily for personal scripting tasks:
Your work is a very useful thing to have, but let me suggest there are additonal issues to consider.
The Allegro machinery allows a compiled file to be included as the application. This eliminates the time necessary to cl:read the source and compile the definition on systems that automatically compile. For many scripting applications none of this matters. For most purposes interpreted executions, and/or the compiler, now require such inconsequential time that one shouldn't care how the deed gets done. But there are situations where it might:
If the script does nontrivial computation, the difference between interpreted and compiled execution might matter. (For implementations that always compile, the compilation cost is fixed, but happens upon each execution.)
If the script is executed with high frequency, perhaps as the implementation of a web page, the cost of launching a heavyweight Lisp image in almost _any_ implementation is likely to be objectionable. A lightweight C a.out has a small footprint in addition to the various .so libraries it uses, which will tend to stay loaded, and requires minimal startup execution overhead. Most Common Lisp applications have a larger startup cost because Lip environments are, shall we say, bigger and more capable.
It would be nice to think further how startup overhead could be reduced with precompiled execution