I just took a quick look - nice stuff! (bookmarked for later).
I spent most of this morning refactoring some old Common Lisp code, separating the LispWorks CAPI code, planning on adding Common Graphics and McCLIM front ends also. Common Lisp (for me) is the least resistance of any programming language I use. Love it.
I certainly wouldn't call it "least resistance", simply because I never use it enough to be completely comfortable with even some of the basics (i.e. loop). Always hitting the hyperspec about something.
But, even then, I find it's much easier to write in simply because of its syntax.
I use dashes-in-all-my-identifiers. Those are very easy to type. Most of my routines break up easily in to "bunch of assignments and destructuring in let" and then "code to work on those". All of the argument lists and structures and what not are broken in to their component bits early on, then its "just code". It's very stream of consciousness then.
That said, however, I have not done a lot of interfacing to external libraries. It's mostly just me and the listener. But, even with me constantly bouncing back and forth doing prefix math (my little brain doesn't think far enough ahead to naturally use prefix math), it still flows really easily.
My experience with CL (as someone who loves it very much) that while the syntax is relatively easy to use (with the CLHS caveats that you mentioned - does the list or symbol come first for GETF? is it TYPE-OF or TYPEOF?), there's friction around getting set up for the first time. I've tried to teach it to many people before and getting a sane development environment is orders of magnitude harder than with Python.
I find your "stream of consciousness" description to be very accurate, and it's one of the most addicting parts of it for me.
Now, if only it scaled better to larger systems, it would be perfect - I would like to have better types and type-checking, and macros that have access to type information, for starters...
Assuming you can convince people to give emacs a try (shouldn't be hard if they're convinced to give Lisp a try and otherwise don't have preexisting biases against emacs for other reasons), getting setup for Lisp is as easy as installing Portacle (https://portacle.github.io/). It and any decent Lisp setup includes things like a hotkey to autocomplete, so you just type 'typ' and tab or whatever, and out pops suggestions like 'type', 'typep', 'type-of', ... and so you don't have to remember spelling; similarly they all should have some sort of intellisense to minimize trips to the CLHS or jumps to source code. I'm a vim head (which is why I don't know what newbie setups are like anymore apart from doing it in vim) but even when I type "(getf " I'm shown at the bottom "(getf PLACE INDICATOR &OPTIONAL (DEFAULT NIL))". If that's not enough, I can jump to source with "ctrl+]" (really nice being able to jump to the Lisp implementation's source for built-ins too without having to do anything special -- can even modify it live by adding print statements or whatever I want), or typing ",s" to get the symbol's describe output (I mainly like it for getting the docstring -- if memory serves though Portacle gives you the docstring with the lambda list in an intellisense popup automatically, like a Java IDE), and if I really need to ",h" opens a browser tab to the hyperspec page on that symbol.
If Portacle isn't one's cup of tea, it becomes a bit harder, but I don't think it's "orders of magnitude" harder... Compared to setting up a local (L|W)AMP environment back in the mid-late 2000s, which tons of teens learning PHP did, it's a piece of cake. You install a Lisp implementation (like SBCL -- http://www.sbcl.org/platform-table.html if your distro doesn't package it/have a recent version), configure it to use Quicklisp (a couple commands -- https://www.quicklisp.org/beta/), and consult the CL Cookbook for further basic steps on setting up the best environment you can for a variety of editors (https://lispcookbook.github.io/cl-cookbook/editor-support.ht... -- emacs, vim, VS Code, Atom, Sublime...).
For scaling, CL has scaled to multi-million lines of code projects, it scales fine. If you want more sophisticated type checking, there have been solutions over time, but in case you missed the latest and greatest take on it: https://github.com/coalton-lang/coalton