No the license cost is fairly marginal in overall development costs. Rather it's an embedded system of numerous (hundreds) networked devices so it limits what kind of development and tests you can do on your laptop†. In the end you have to attach to remote images for debug sessions.
CCL happened to have threading support on Arm32 target we use so that's how the development historically started. LW license was procured later: we gave it a run and turned out the tree-shaked binaries it produces use much less memory. We're comfortable running it on a 128Mb RAM (single core) SoM as a part of embedded Linux build.
† That said we do have a simulator for the product running on a 64c/128t server. It however mostly tests deployment/procurement/networking part of the thing rather than physical component it operates on.
The threading support was lacking on SBCL, that's the reason we started on CCL. It is of course there on LW or we wouldn't be able to deliver.
Point is if I have to attach to remote hosts anyway I might just as well continue to use Emacs Slime rather than learn the ropes of LW's own remote debugger. Also LW license allows for unlimited redistribution of deliverables (that you can't however attach to) but the compiler itself is licensed per seat.
CCL happened to have threading support on Arm32 target we use so that's how the development historically started. LW license was procured later: we gave it a run and turned out the tree-shaked binaries it produces use much less memory. We're comfortable running it on a 128Mb RAM (single core) SoM as a part of embedded Linux build.
† That said we do have a simulator for the product running on a 64c/128t server. It however mostly tests deployment/procurement/networking part of the thing rather than physical component it operates on.