http://www.rebol.com/article/0103.html
Language that hits the sweet spot between Forth and Lisp might be a good fit for some kids, but its scope is way outside of mere scripting and toying, and demands a respective approach - something that only grown-up engineers can fully appreciate. YMMW.
Maybe I misunderstand where you are coming from, but to me this appears similar to saying that using acrylic paint demands a respective approach because the great paintings of the last century were made with it.
To which I would say: no, not really. Acrylic paint only demands a respective approach in the sense that it may be toxic and you don't want kids to finger paint or risk swallowing it. But people can paint whatever they want with it.
Similarly, Red demands a respective approach because it's powerful enough to shoot yourself in the foot (oops, some kid deleted half of the files on the SSD by accident). Maybe that is what you meant with "scope", but it's not what I made out of it upon first reading.
Besides, the solution for that is simple enough: make a child-safe dialect.
But that doesn't mean that these languages child-safe by default, and indeed, foot-shooting starts as soon as you begin to harness that power - that's where the real fun is, which IMO kids can't appreciate fully. As you said, it's anything but a finger paint.
But if it clicks in kid's brain from the get-go and grows over him, then the world is ought to see some great paintings ;)
BTW, is there a child-safe dialect for Red? How easy or hard would it be to create an environment like Processing or p5.js, without the foot-shooting risks?
Easy - you can create a live-coding IDE in 20 lines or so, Draw and View a pretty capable for interactive Processing-like demos, bottlenecks can be rewritten in R/S.
Hard - hit the academical papers and define what can be considered a "child-safe programming environment". Then implement a separate toolchain for that.
[Somewhere between Easy and Hard?] - make the dialect operate in a safe sandbox that can't destroy your computer
... plus optionally convenience functions fitting for the creative problem domain like how Processing removes a lot of Java boilerplate, and p5 does similar things for using the various JS APIs. One can just look at the APIs of Processing, p5 and OpenFrameworks to get an idea of what works there, though.
Creative problem domain: that's what Red is all about in my point of view - slapping domain-specific languages one on top of another to pin down the exact problem space. Draw for 2d vector drawing, View for GUIs, Parse for, well, parsing and metaprogramming, et cetera. The crux is usage of same data format and common notation at every abstraction layer, be it low-level programming or high-level scripting.
I don't think that Red can handle large-scale projects the way language workbenches do (yet), but it can be used for moderately small embedded DSLs.
Does that answer your question?