Also, there's a small set of programs that don't get along with the abstractions provided by OSes and run better on a virtual hardware abstraction instead.
The intrinsic overhead of the OS (i.e. costs of mode switching) is much smaller than you might think.
It's true that some programs don't really want an OS getting in their way, but a modern operating system provide decent facilities for getting _out_ of the way (e.g. O_DIRECT for block I/O, pinning tasks to cores) and that's usually what those things use.
A userspace process on x86 has a certain amount of overhead, namely the overhead needed to switch between it and the host kernel. This takes the form of SYSCALL/SYSRET (mostly) for system calls and interrupts/IRET (mostly) for interrupt returns. SYSCALL and SYSRET are quite fast. interrupts and IRET are slow.
A VM guest needs to do a VM exit (which is quite a bit slower than even an interrupt, I believe) and then fix up a bunch of host state that doesn't get restored by the CPU. Then, to get back to guest mode, it needs to manually restore some guest state and do VMRESUME.
Regular user mode wins hands down.
To be fair, unikernels get to directly create page tables, which is potentially very useful. But, for the simpler applications, it's probably not.
(I more or less maintain the glue between x86 Linux user code and the kernel. I do, in fact, know exactly how this works.)
Anyway, I don't personally think reducing system call overhead is interesting but it seems to be one of the arguments unikernel people make.