I'd have to read a compelling technical explanation before believing this could perform better than a Linux or BSD kernel.
In most cases, the Go code is going to be single CPU, and that ain't the way the world works anymore. There's going to be a bunch of wasted computing power on that VM
So it's not just that this has to perform better than a kernel, it has to perform better than not involving the kernel in the critical path, and it has to perform so much better that it's worth wanting to beat yourself in the face with a hammer after trying to diagnose the latest lockup. Unikernels are interesting to me, but like the demoscene or a semi tractor doing wheelies. Not for production usage.
Instead of sharing the code at runtime, i.e. what an OS does. You could easily share code at compile time, i.e. statically link a library.
Because of sharable code, "implementing * in application" should always be at-least as performant as the best generic implementation (i.e. the implementation you find in a general purpose OS). However, when appropriate, customizing the implementation for the application would allow it to become even more performant.