I'd kill for common lisp with transparent green threads. It would be so great. As you noted once you use them you can never really go back. Of course, it will never happen because it can only be done in the compiler/runtime, not in a library, and the standard is frozen in stone, so that's that.
I've got some hope for clojure with that at least, thanks to it being jvm hosted.
Back in the 1990s the usual in CL implementations was green threads. Everyone kinda wished for POSIX threads support instead, which was eventually gained on most runtimes.
You can still see the glimpse of them as atavisms in old code and documentation.
I indeed saw this years ago mentioned in clozurecl's documentation. I was very upset that all the support for it got ripped out of the language, because as shown with https://blog.linuxplumbersconf.org/2013/ocw/proposals/1653 (which inspired what is now making its way into Java) this is the way to go for performant solutions with very very high thread counts.
shrug I personally hate cooperative multitasking, and so far never ran into a problem that couldn't be scaled with system threads and use of select/poll. But am sure Google sees its uses.
Web backends. BEAM VM's green threads work excellently for it, you can handle bursty workloads transparently and all you will pay for it is slightly increased latency (and I really mean slightly).
I know, many people claim Ruby [on Rails] and Python [Django] do the same but I've seen APM dashboards of such projects and those of Elixir [Phoenix] and Golang [various, most recently GoFiber] apps and the difference is pretty stark.
But if you mean the golden path of select/poll then yeah, hard to beat those on their own turf of course.
I've got some hope for clojure with that at least, thanks to it being jvm hosted.