A couple of decades ago Java was riding pretty high in programming language circles. It used the JVM, and back at the turn of the century it seemed that pretty much any language was going to end up being run on some kind of virtual machine. Two decades on and it's a little difficult to say what the point of a virtual machine is, any longer.
At the time, it was not easy to see that most of the software we use was going to be moved into the cloud, and whilst somethings are interacted with using smartphone applications, much of it is done using a web-browser. In a sense, the web-browser has replaced the need for a virtual machine. Most of us did indeed see the value in compiling one application and being able to run that application on different machines. Although the virtual machine concept never really paid-out that kind of cross-platform dividend. Even if so, you have to wonder whether it really was easy to develop a virtual machine for different platforms, rather than just develop a compiler-target for different platforms.
On the server, the case for the virtual machine is particularly weak. The server code only has to be developed for one architecture, you do not need to run it anywhere else. Okay, so maybe you want to run it on your development desktop for development, and then on the server for deployment. There are many solutions to this that do not involve virtual machines (at least not language-based virtual machines). You could, for example run it in docker locally. Or you could just provision a separate development server. In any case this seems a pretty solvable problem without the need for a virtual machine. In addition, presumably you care about the speed of your server, and for all the benefits of virtual machines, there is some performance penalty. Even if you utilise just-in-time compilation, you have to wait until all the 'hot' code has been compiled, you'll still get a hit when actually warming up the service or when running 'non-hot' code. Finally, just-in-time compilation is unlikely to make use of heavy optimisations that might be available to an offline compiler. All-in-all virtual machines just do not seem appropriate for server code.
There are a bunch of services that a virtual machine can provide, most notably garbage collection. Most of these are easily provided either by a library or by the output of a compiler. Some other services are just wrappers around their operating system counter-parts, these are no-doubt useful, but could be as usefully wrapped by a library as much as a 'virtual machine'. Arguably, the web has become something of a virtual machine, providing a set of UI components, as well as the WebAPI which allows interaction with such things as the local file-system, location, webcam etc.
On the client, a virtual machine can be a bit of a boon to cross-platform development. Even here though it's relatively rare that I cannot just create a web-based application even if I then have to wrap it in Electron. The main reason for this is that you perhaps currently believe you want a native application for several different platforms, but sooner or later it's likely you will get a requirement to interact with the software over the web, or more generally remotely, wherein a web solution would be a fairly obvious candidate. At that point, you're probably going to wish that your entire client applications were web-based.
So, all-in-all, aside from the fact that the web platform is essentially a fairly nice, if far from perfect, virtual machine, I just don't really see the need or even use of language based virtual machines today. Maybe things will cycle back around and there will be some good reason for them to re-emerge but at this time they're pretty much unnecessary.