I'm pretty sure the v8 changes were motivated by phones, so maybe there is room for another project like Graal and Truffle with a different set of constraints.
Also, for web services in particular (not sure if that is a major use case), I would question the view of making individual requests faster. I recall Steve Souders said he was a back end guy at Yahoo working on latency, and then he switched to front end performance because he found that the front end was eating up all the time.
In my experience this is too true. In other words, if you had a server where requests were taking 100 ms, and you made them take 50 ms through VM design, you would be a hero! But somehow front end engineers are still constructing pages with 10 - 30 full seconds of latency (especially on mobile) out of back end requests that take 100ms. There's just a lot more room to optimize there, whereas sometimes I feel like VMs are trying to squeeze blood out of a stone.
And I agree that there will be demand for such a "black box" approach, where you just take an arbitrary program and make it faster. But I'm interested in overall system performance, and in that case, a little bit of application knowledge can work wonders. One of my pet peeves is that often performance tools like time and space profilers are sort of an afterthought that programmers use only when they have problems. They write this huge spagehetti of allocation, and then 2 years later they start tuning the GC.
This is partly the fault of programmers and partly the fault of the language ecosystem. It would be nicer if the language exposed integrated tools. I dont' know that much about the JVM ecosystem, but they always feel like a "separate thing" you have to go research and choose and download and install. I think Go's tooling is a good example here.
Anyway, I think this is an interesting project. In particular I think the focus on polyglot programming is fantastic. I too feel the pain of enormous amounts of duplicated work -- e.g. even at say Google with a relatively small set of languages like C++, Java, and Python, there were still all these separate "worlds" and gradually engineers became sequestered in their own world. IMO Go made things worse and not better -- it was yet another native runtime that didn't even interoperate all that well with C++, let alone Java or Python!!!
The startup time issue is being solved with ah ahead-of-time Java compiler with whole-world analysis that we are developing. It runs hello-world in our Ruby implementation in about 100ms, which is an order of magnitude faster than the normal JVM.