Best case scenario in simple terms, is that if you are interested in Cycles only, your most logical approach would be to use OSL.
At some point I was very interested in nodegraph-scripting hybrid approaches as well. Here I did a very simple experiment as you can see and it worked really great! I think that there are unlimited capabilities in that style of programming to combine the best parts of nodegraph and scripting at the same time.
The real bummer in this case, was at that point in time (that year) Cycles rendering was not efficient so I abandoned the idea to invest more time to it. (I was interested only in rasterization at that time).
Now I think that Cycles is starting to become top-notch again, since it has lots of improvements and innovations compared to 10 years ago. You get for sure better hardware for more raw power. Then you have denoising which is a huge deal as well. Then you get great innovations on the Cycles-X project which is far faster and efficient due to a complete refactor of the architecture. All of these factors are enough to start placing Cycles once again on my primary choice of rendering.
While I still like EEVEE and I am still interested to it, but I can’t deny that is a huge bummer that there is lack of programmability. There can be lots of techniques to do the job behind through third party means, but essentially it like you are trying to do duct-tape engineering, is not exactly the best way.