I like the idea because it is thinking outside the box,
the only problem I have with it in theory is that youre launching more httpd threads on the server, and sending more overhead in the http requests. I don't think it would be practical performance wise but it definitely has its applications if you're willing to think out of hte box a little
Some of the best innovators in our history were laughed at when they proposed their ideas initially. I think this could be good where you have a view divided into multiple views, and you need to update different views at different intervals, without reloading the whole display for instance. Didn't download your code but you could also have your "threads" act as persistent servers, so the scripts could create "threads" within javascript as well.
A different idea would be to have a standalone script for your "thread" manager and have it call itself using the "nohup" utility in linux, runing on CLI
nohup is a Unix command that is used to run another command while suppressing the action of the HUP (hangup) signal, enabling the command to keep running after the user who issues the command has logged out. It is most often used to run commands in the background as daemons. Output that would normally go to the terminal goes to a file called nohup.out if it has not already been redirected.
You could even have your output redirected somewhere so the main thread can view the status of it's "child" threads