Agree. I think there is one reason only why lisp/scheme are not mainstream: community.

1. Ruby + Clojurescript have prominent, opinionated community leaders who spend an immense amount of resources on proselytizing and preaching agreed-upon best practices (hell, 90% of Ruby development is done within a framework that all but forces you to write code in a particular, proven way).

2. As for JS: web developers are all forced to use it, which naturally leads to less fragmentation (if Chicken Scheme was the only scripting language available on a UNIX OS, by necessity some libraries would become dominant). Even then, most large enough JS codebases are ghastly.

---

Contrast that with Lisp/Scheme. I am now learning scheme, and love the language to point that it's depressing not to get to work in it on a daily basis. That said, the most impenetrable aspect of scheme/lisp is not the language, it's the community:

I don't think I'm exaggerating if I say that the entirety of the scheme community (with the exception of racket) is scattered into completely fragmented groups of under 20 individuals, all of whose landing pages look like they were designed in 1993, filled with broken and outdated links; libraries are maintained and abandoned willie-nillie, communication happens mostly in the form of mailing lists... where do I go to watch a talk? where do I read about latest libraries and projects? what are some of the agreed upon best practices?

"Read the SRFI" is not documentation (if you can figure out the relevant SRFI in the first place).

Example 1: this is the package manager Gambit Scheme recommends http://snow.iro.umontreal.ca/ -- a noble attempt at unifying scheme packaging across implementations. DEAD (as far as I can tell). And why? Because each scheme implements its own unique module system, implements its own unique subset of RnRS.

Example 2: need an LMDB library? Well, the chicken scheme version is a port of a version that exists only within the LambdaNative framework (which is implemented in a different scheme). Why does it have to be ported? because the two schemes have an incompatible way of handling c-bindings. So one can't just write a library that's R5RS compliant and assume it works across implementations. So we end up with two developers maintaining two versions of the same library, instead of both focusing on the same one. And when one of them decides to start using leveldb on his projects instead? The project is DEAD.

(I'm not arguing for a singular implementation of scheme. Part of the beauty of the ecosystem is the variety in implementations suited for different purposes. But so many of the incompatibilities are trivial, and are a community problem, not a technical one. If everyone agreed to implement, say, R7RS-small and better efforts were made to standardise the trivial, like how modules are defined, or how c bindings are to be declared, we could have a central repository of cross-compatible packages.)

The problem isn't the language or its power, it's a lack of community building efforts, which makes it extremely frustrating for a newcomer, even one who is absolutely enchanted by the language; and downright prohibitive for a company to bet on scheme.

Imagine you are a project manager, would you gamble the success of your company on a language whose libraries, as far as I can tell, almost ALL have a bus factor of 1?

tl:dr scheme needs a modern, newcomer-friendly, robust community portal. When there is one link I can give to people where they can find: practical tutorials, lectures, a quick overview of the ecosystem, portable libraries, books and articles full of tips and best practices, charismatic community leaders (who explain things in simple terms that don't scare off the uninitiated, as opposed to trying to convince you how much smarter Lisp programmers are)... then there will be no reason for the language not to be widely used.