And there is nothing inherently inefficient about the Linux kernel. It's more that once you pack on all of the userland components you do end up with a sizeable attack vector.
The first thing that comes to my mind is the user space networking drivers for linux [1]. They aren't very ergonomic, but the massive speed increase that is possible shows how inefficient normal linux networking is.
The promise of unikernels is the speed of user space networking but with good ergonomics.
Like I said earlier, if I had to bet, I'd bet on Linux.
But there is work to be done.
___
putting an app in a unikernel may be about as clever as possible for a great many software engineers.
I think the traditional argument is that, with a unikernel, you can cut out a lot of the traditional OS systems that you may not care about. In theory, this could reduce your overall system complexity.
This may not really be a difference in the future anyhow: with the success of BPF programs, it may be possible to get pretty close to a unikernel while still sticking with largely vanilla Linux.
I think the most charitable translation of this is that the OS inside the container (e.g. Alpine Linux) + application will be replaced with a single unified OS + application i.e. unikernel.
I don't think that this is true, but it's a seductive idea.
From what I can tell, as system complexity goes up, you need increased instrumentation in order to property debug your application. That is a lot of what modern OS's provide.
I do sympathize with people making efficiency arguments, but I always try to bet on the "strong horse". There is just so much money and effort going into Linux, that I think it'll get efficient faster than unikernels will get instrumented.