So why lisp can't compete with mainstream JSON parsers?
1.LISP syntax is disgusting and deters developers(SRFI 110)
2.Most Lisp/Scheme compilers are transpilers that rely on C compilation as optimization, with exception of Stalin Scheme that does real flow analysis.
3.LISPers tend to create 'elegant macro' stacks that are hard to optimize, but fast to write. Performance code thus tend to call compiled static C/C++/etc functions.
4.Lispers tend to avoid benchmarking code or measure memory use.
Code that competes on elegance/beauty/length alone is like code golf - no one uses 'code golf scripts' for actual work.
so while you might gloat how 'elegant, short and intuitive' is to
write inline JSON into (horribly inefficient) linked list trees
that get parsed it just like other 'executable XML' glue that binds this heap of lambdas and functors together, it doesn't change the mind of other programmers.
These programmers don't have your 'paradigm values' as center:
They don't care about how 'hard' is to use something if the process
yields better results in the end, after all everything that is 'hard' is eventually automated and scripted away.
The 'elegance' only lasts a moment, its 'beauty' is external appearance of simplicity that doesn't correspond to internal state of the thing. LISP isn't going to get far with its evangelists
stubbornly advocating that "LISP way is the only way to program".
Instead of looking at "how can you even like this disgusting, imperative, dirty(insert more epithets) language that doesn't even do X" you have to look at results:
C/C++ code is shown to be faster, more efficient in terms of algorithm complexity and memory use, which in turn create demand for it.
Lisp code, which seems elegant(short and simple)/beautiful(mostly to Lisp programmers who tolerate this parens soup, that most view as nuisance) in reality doesn't produce results that encourage its use and software market doesn't value it much.
In the intermediate niche of scripting languages Lisp is out-competed by user-friendly Python/Lua/JavaScript that allow to
develop software fast with a natural ALGOL-type syntax.
In the field of secure computing Ada,Haskell and Rust dominate due to their type systems and integrity checks. LISP simply isn't secure and 'code as data' is widely considered a bad idea for safety.
I feel the whole idea of LISP features being useful in completely different language model is misguided,
these features are only useful inside the paradigm of functional programming and many are too lisp/scheme specific to be useful elsewhere - its highly unlikely something like 'reader macros' will be adapted by C/C++ in their LISP form, unless you somehow convince
the C/C++ standard committees to extend the preprocessor(some people preprocess C/C++ with scripts to achieve more flexibility)