CL can be used pretty much anywhere nowadays, even on the web with ECL wasm compilation.
I wish more desktop applications could hit even a 100ms startup time. These days it feels like 5 seconds or more is the norm.
Web services need either cooperative concurrency or M:N concurrency due to the "10k problem". CL only supports threads (OS-level) and promises; everything else is incomplete (eg., delimited continuations, which could be used to build coroutines) due to missing parts in the spec and some language features (eg., conditions and restarts). Of course it can be done, but it won't be as pleasant as using Elixir and Phoenix.
A game engine would work, most likely, unless it was for an MMO (again, concurrency handling). I personally never worked on one, but I see examples of game engines in CL, and they tend to look nice.
In general, single-user desktop (CLI, TUI, GUI) apps are still a good fit for CL, even today (you need to put some work into packaging the app for different platforms, but it tends to be easier to set up than it is for C or C++; harder than Go or Rust, though). It's unfortunately not as good a fit for the backend, at least not until an implementation with good support for concurrency appears. It's nice as an extension language in a larger app (through ECL), and as far as dynamic languages go, it's quite performant, so some computation-heavy apps can benefit from using CL (with SBCL). On the other hand, the ecosystem is quite small, which means dependency-heavy apps are better written in something like Python or a mixture of CL and another language (there are two-way bindings to many dynamic languages and there's mature FFI support for compiled languages).
To be perfectly honest: as much as I love Lisp, I personally gave up on trying to use it, for now. For hobby stuff, I found an even more niche solution that is more enjoyable to work with in the GUI/TUI/CLI space. It also doesn't support OS-level threads, but instead provides coroutines for concurrency - I find this side of the trade-off to be useful/beneficial more often, at least in the code I tend to write. I don't believe the time spent learning CL and other Lisps was wasted, but it's become harder and harder to justify going for CL over the past 15 years, and I finally reached a point where I stopped trying. YMMV though, and I would still give CL a chance if it's your first language of this kind (i.e., providing image-based interactive development, a dynamic language with a native compiler with inline assembly support, a multimethod-based object system, and homoiconicity/macros, etc.).
What is that solution?
I don't remember the exact numbers, but when I checked, the GT+Pharo ecosystem (available packages, number of people in Discord, tools with support for the language, etc.) was ~2x smaller than Common Lisp's. It also comes with its own problems, some of which CL doesn't suffer from (the GIL, performance, startup time). But it's very fun to use and play with, which is the most important quality for me in my hobby/side-projects. :)
I'm confused by the GP's assertion that backends aren't a good fit because of the threading model, to me they're one of the best fits. The 10k problem isn't a concern for most software, and in any case there are ways around it. (I don't know what Google Flights does but even at their scale they haven't moved off SBCL. And Hacker News itself runs fine on SBCL, though there probably aren't 10k concurrent connections.) In the ecosystem, there's the https://github.com/fukamachi/woo webserver which binds to libev to handle similar scale as Go was advertising about 10 years ago. And besides some work going on recently on the SBCL dev mailing list to add native fibers/green-threads, there's been non-native versions of them before, and basically any concurrency model you can think of has been built on top of SBCL by someone. (STM, actors, async (one even built on libuv), channels, promises/futures...)
> The startup is of course nowhere near that of a small C or Zig binary, but for larger tools it will be tolerable.
It's worse than Java and Python and JavaScript I think? The languages that were always disliked for CLI/TUI/GUI apps because of unnecessary bloat they bring due to their runtimes. It's not impossible to use this ofc, it's just inferior to alternatives with minimal runtime, so such an app might be considered a temporary solution to use before someone rewrites it in Rust or Zig or C and people have no reason to use slower and more resource hoggy version. Many people even choose to avoid Emacs for slow startup times, now imagine if something like grep was starting a virtual Lisp Machine underneath. This is why I think it's more promising to consider it for apps and niches that people never tried to keep minimal, such as games and webservices, even if it doesn't have native coroutines or whatever. Using non-standard solution is almost a non-issue and invisible to end user while startup times and RAM usage are very visible.
Also, ofc there's definitely unique things that become available with something that's just as programmable in runtime as it is in development stage. So some kind of very polymorphic app that benefits from growing more native code in response to user actions, could benefit from it. I don't have many ideas of what app really needs this though.
In the past, like two decades ago, I've seen a person using SBCL with some kind of unofficial continuations or green threads for backend webdev in commercial setting. I also remember someone using it in context of virtualization systems, but don't remember their exact usecase.
Also quick search shows there are some modern takes on coroutines as well: https://atgreen.github.io/repl-yell/posts/sbcl-fibers/