So the important point in your question is why a new VM and not a java VM. ok let's choose a Java VM instead, what do we get? :

**1**- **complex** Bytecode (class) => how to store it, in the blockchain for which cost?

**2**- **useless features and security concerns**: Network access,I/O stream, File W/R ... =>each of these features implies big security issues. think of it, you can write a code which ping (of death) another machine or access protected files or even steal the miner's private keys. Even sandboxed a flaw could occur and file "write/read" feature could break the whole system's security. so we'll need to get rid of all these features, which is a hard task to achieve for a licensed VM.

**3**- **JAVA VM is a** **licensed** **Sun product**, so you can't customize it to integrate it to the Ethereum's environment (for example how would you calculate gas cost to avoid Dos attacks?)? to overcome this problem you need to write your own Java VM which is a complex task read : https://softwareengineering.stackexchange.com/questions/71561/java-and-jvm-license.

**4-** if you use JVM that means you will use **Java** or another JVM language, which are not adapted to the blockchain context(determinism, memory access ,latency, etc...).

check out this answer :
https://ethereum.stackexchange.com/questions/3112/what-is-the-merit-of-creating-new-smart-contract-languages-like-solidity-instead