What any server-side javascript implementation needs to thrive is a set of solid, fast database client libraries (MySQL, etc). That, to me, is why some of the JVM-based alternate language implementations are so interesting -- because the database support is built-in.
Agreed, if there was some sort of external support, server-side JS would be amazing considering the speed war that's going on with the different implementations. I messed around with WebKit's SquirrelFish which was nice and fast for the bare bones of the language, but many important functions are in window.* which isn't available on the compilable terminal app.
Unfortunately Rhino is at least an order of magnitude slower than all the modern JavaScript engines (SquirrelFish Extreme, V8, TraceMonkey). I agree the JVM integration is very useful, I just wish there were a way to get the best of both worlds.
Port https://wiki.mozilla.org/JSctypes to v8, get C libraries for, well, cheap if not actually "free"... probably wouldn't take that much effort, but I'm just guessing. For bonus points, start sharing JSctypes-based wrappers between the two implementations.
Actually, if you're serious about JS-on-the-server, that's probably just about the most useful single thing you could possibly do to help it. Well, unless you're really attached to the JVM...
