Joanna Rutkowska, leader of the Qubes project, does a great job into documenting the concepts on which Qubes is relying. I therefore strongly suggest you to get the information at the source, and in particular to read the two following documents:
Qubes not only brings user experience improvement compared to running several vmWare instance, but it also brings a more fine-grained isolation.
To explain it roughly, the model you describe is like putting a set of smaller boxes (the VMs) inside a single big box (the host system). All VMs will go through the host system to access any device (network, USB, DVDs reader, etc.), and the host system both controls the VMs, the devices, user's interface and is directly facing Internet.
The idea behind Qubes is not to store the small boxes into an overpotent big box, but instead configure the small boxes in a kind of virtual local network so that, together, they look like a big box without being one and without using one.
The need to look like something users already know is important for user's adoption. But behind the scene all parts of the system is meant isolated from each other. Among the main differences are the fact that the user interface is not facing the network and has no Internet connection. The VM dedicated to facing the network is isolated from the rest of the VMs by another VM dedicated to firewalling. Qubes 3.0 brought a long awaited feature allowing to have a VM dedicated to USB devices.
To see this from and attacker point view:
If I want to hack your Windows based solution, all I have to do is to manage to exploit your Windows host (single point of failure). Once I get it, I get power on everything and this should be relatively easy since it is facing the network, allowing a wide range of possibilities from remote exploits to reverse shell trojans.
If I want to hack Qubes, I will have no choice but starting at a guest position since neither Xen nor the main Dom0 domain has any direct link with the outside world, and from there find a way to migrate from guest to guest or manage to exploit Xen core or reach the user's interface running in Dom0 (knowing that the guests have their X server replaced by a specially designed hardened display server to precisely avoid such possibility. All inter-VM communication in general has been carefully designed to reduce any exposure area to the minimum), and build the appropriate tunnels in order to still be able to communicate with your malicious software (going in is not sufficient, you also want data to be able to go out, which is trivial on a network facing system, but much more harder on isolated guest systems).
I just want to add that while Qubes OS is the most well-known and most documented as being, as far as know, the only open-source initiative implementing this concept, the concept itself is not something completely new and revolutionary. Polyxene for instance is a proprietary system taking exactly the same approach in order to secure defense-level desktop systems. I say this just to highlight the fact that discussing such technology goes beyond discussing open-source and proprietary OSs.