I suspect the main advantage of a system like this (basically, userspace code is run in a software VM) would not be code synthesis (though I do think that is also useful), but the fact that there's no longer an expensive boundary between "user" and "kernel" code. A system call would simply be a regular function call; there would be no use of interrupt handling or manipulating/switching page tables or ultimately any use of an MMU.
Once this boundary is removed, we won't need things like userspace buffering, which exists to circumvent this expense at the expense of some odd user behaviour:
$ cat | grep a | cat
Ultimately, I do think that OSes will go in this direction. As mentioned in the article, there are currently things like eBPF in Linux which take advantage of this. I don't see why we couldn't have a kernel which supports both running VM code in "ring 0" but also supports a Linux-like VM mechanism for running computational code which would be compiled sub-optimally by the software VM. Presumably this functionality could be implemented directly into an existing OS, so it wouldn't necessitate some major switch.
Running userspace code in a kernel VM isn't what John is suggesting, and the experimental OSes that tried this tack have been hit rather badly by the Intel speculation security problems.
Once this boundary is removed, we won't need things like userspace buffering, which exists to circumvent this expense at the expense of some odd user behaviour:
Ultimately, I do think that OSes will go in this direction. As mentioned in the article, there are currently things like eBPF in Linux which take advantage of this. I don't see why we couldn't have a kernel which supports both running VM code in "ring 0" but also supports a Linux-like VM mechanism for running computational code which would be compiled sub-optimally by the software VM. Presumably this functionality could be implemented directly into an existing OS, so it wouldn't necessitate some major switch.