To go from "We can send your web server an HTTP request" to "We own your datacenter."

I think he's implying something that would be remotely exploitable on a server running the JVM for a service with an open socket. Which is very common. Also the the File API could potentially be exploitable (if a vulnerability exist) remotely also if for example it was used for file uploads or something. Seems non-trivial but I can see how it could happen.

True, if there was a vulnerability where reading a byte stream could trigger a JVM exploit, that is exploitable. But that would be a really weird bug, since the JVM isn't going to be the one parsing a byte stream.

There is also the standard library, it does a lot of stuff that could hide a vulnerability.

Most JVM methods can require permissions because it provides built-in POLA ACLs (security policies). The default would likely be to deny network access and file io. It's more likely that an app itself contains vulnerabilities &| unnecessary weaknesses due to ease of misconfiguration because of the pervasive lack of full-stack implications, grokable and auditable security policies.