Again, just passing around a javascript function doesn't mean it's a shader. Javascript isn't running the GPU and javascript isn't doing any rendering.

Shaderpark does a bit more than "pass around" javascript functions, it transpiles them to glsl. Believe it or not, web browsers themselves only transpile webgl shaders to other high level shader languages: hlsl on windows, msl on macos/ios, and glsl or sprir-v on linux. The os then compiles these to bytecode, and the driver finally compiles them to machine code which is sent to the GPU. So a webgl glsl shader isn't "running the gpu" or "doing rendering" any more than a js shader. They're both just high level languages at the top of a compilation chain ultimately targeting the GPU.

This comes back to the original question, why compile javascript to glsl? I don't think you ever answered that. There are severe limitations in shading languages that javascript doesn't have and shading languages are made to deal with. Where is the benefit?

Have another look at the first example I shared. One major limitation of glsl is a lack of functional programming. In that example, we pass functions to other functions, and iterate over arrays of functions, neither of which are possible in glsl. This is used to implement generic transformations of SDFs. If you did the same with just glsl it would be much longer, harder to read, and there would be duplicated code.

You can even use recursion (with limitations of course)!

https://shaderpark.com/sculpture/-N8ntgGcPiXK5igOagRW

At the same time, many more people know javascript than shader languages, so this makes it easier for beginners to get their hands dirty and can be a gateway to gpu programming. So there are benefits for both novices and advanced users! There are pitfalls to this approach too of course and it certainly isn't a replacement for glsl, but the purpose is simply to explore new possibilities :)