I'm a hobbyist, I don't use common lisp professionally, but it has become my go-to tool for little personal projects and puzzles (like Project Euler or Advent of Code). The interactive development (mentioned in the article) is one of the primary reasons.

I find it so fun to build with. You can write functions and immediately test and interact with them in the repl, and then build on them from there. You can compile code at a granular level - for example you can recompile a function rather than the entire source file. This is helpful if some stuff is still being worked out and would produce compile time errors.

Occasionally I've gotten into a weird place because of the evolution of my code and incremental changes along the way while running a program. When I stop and completely reload a program, it behaves differently from what I previously experienced. It is something additional to keep in mind when interactively modifying a program.

The debugger experience with Emacs/Slime is the best I've experienced (professionally I've used various versions of Visual Studio, and as a hobbyist, various open source IDEs.)

The programs I have written are simple. Some day I would like to grok CLOS and the condition system.
- @ItsJason @cadar I've been doing Common Lisp for 20+ years also as a hobbyist and I'm somewhat familiar with CLOS and not really with the condition system 😅
  
  Not that it's difficult, I wouldn't know, but it hasn't been necessary for the kind of programs I write... apparently.