The other unikernel projects (i.e. MirageOS and HaLVM), take a clean-slate approach which means application code also has to be in the same language (OCaml and Haskell, respectively). However, there's also ongoing work to make pieces of the different implementations play nicely together too (but it's early days).
That's a good argument but seems to be one for rump being the past's future (unikernel-ifying legacy applications) rather than for it being the future itself.
besides, think of all the future cool stuff you can more easily build on top of rump kernel (almost a year in the IRC channel and I still can't recall how I'm supposed to refer to...it) rather than being "stuck" with just Erlang on LINC or Haskell on HalVM etc.
Being able to build your unikernel (micro)services using legacy things and then swapping out certain services for clean-slate versions seems like a much more palatable approach. This is why unikernels fit so well with the microservices approach — you only have to re-write things one piece at a time if you choose to.
That's kind of my point, in that worldview rump kernels are not really the future they're a transitional phase bridging the present and the future.