It is not as efficient as a system-level one like Xen or KVM.
i.e. Vbox is an application that runs at the same level as say... apache or nginx as opposed to KVM and Xen which work at a lower level by integrating closely with the Linux kernel.
That means that the resources allocated to Vbox are decided upon by the OS, with all the overhead that comes along.
Xen and KVM can run a guest OS with less overhead than Vbox and can decide that a guest OS has 25% of CPU cycles while another has only 10%, which vbox cannot do.
VirtualBox works fine for development environments, but you want something like Xen or KVM for running your servers if not going bare metal.
VirtualBox is basically the same as KVM with the exceptions of 1) their kernel modules are not upstream 2) they put a lot of effort into doing dynamic translation for non-VT/SVM hardware 3) their performance is really poor 4) they don't integrate very well with Linux mainly because of (1).
As far as being a hypervisor however, Vbox is strictly a type 2, i.e. it needs a host OS to run and resources are allocated to it.
In contrast, Xen and KVM are type 1 hypervisors, meaning they themselves allocate resources for guest OSes from bare metal.
There are debates about the semantics of whether KVM is type 1 or type 2 due to its implementation on top of the Linux kernel, but it is definitely in a different league than Vbox.
The problem is that the phrase used in Popek's paper is "Conventional OS". This was the 1970s. What's now considered a "Conventional OS" was not conventional back then.
For instance, everyone would agree Linux is a conventional OS but Linux provides a kernel module (KVM) that allows for virtualization driven by userspace.
