uLisp includes a mark and sweep garbage collector. Garbage collection takes under 1 msec on an Arduino Uno or under 3 msec on an Arduino Mega 2560. I wonder how predictable and controllable that is. Adding GC to what is likely to be a real-time device seems like a potential showstopper. But if the numbers can be a bit more firm, or if the application can receive alerts on pause / resume, that might not be such a big…
This is the approach of e.g. Naughty Dog's old GOAL language: it isn't doing Lispy things in the engine code, so much as using Lisp as a very powerful macroassembler. This approach is potentially advantageous over having a batch process to compile and upload to the device since it presents some important groundwork for doing "live editing". The performance of the shipped application is effectively unlimited, since the user code has so much control over the resulting output.
The main downside is that the resulting app isn't designed for portability, being so oriented towards the machine code rather than an abstract layer: Getting the portability and the live-editing functionality and the performance is a considerably harder problem to visualize, but production C++ game engines are doing it now.