This is called "sandboxing" and contrary to being a "radical departure from the original Internet", the Java VM has been doing this in the applet engine since the mid-90's. It's a complicated platform to work with, though some applications do rely upon it, and it's the source of the most high profile security holes found in the Java platform overall (https://www.google.com/search?q=java+sandbox+vulnerabilities).
The Java sandbox was actually really close to something that worked well. If you look at the Java virtual machine, it's actually quite simple, and very easy to ensure that nothing "bad" happens. Where Java lost the battle was in the provisioning of APIs which, you know, actually let developers do things like draw windows or load trusted code dynamically: here, it suddenly became necessary to trust huge swaths of code to do the right thing, and the Java sandbox got fucked. If you look at all of the sandbox vulnerabilities, they are never "Oh, the JVM was implemented incorrectly" and always "Oh, some API wasn't implemented properly." That's the key observation.
The other place Java lost the battle was in sticking to a closed, vendor-dictated implementation, that's slowly getting pulled into the massive hole of suck that is Oracle.
True, for the same reason that you don't see (m)any programs based on purely functional programming paradigms. Things with no side effects, no vulnerabilities, and no coupling to the outside world tend not to be very useful.
Pure functional programming does not mean there are no effects. The name "pure functional" is a misnomer, in my opinion. It just means "typed effects" -- keeping track of what effects pieces of code have.
