What you're saying, I think, is that the SELinux could have been used to encapsulate the host process from the rest of the system. Which is true, but sort of specious. Traditional unix security paradigms (e.g. run every guest instance in its own UID, whatever) would have worked fine to mitigate the damage too.
SELinux/Apparmor defeat most of the latest vulnerabilities in QEMU.
Outside the guest, sure, you could use SELinux to firewall VMs from access to anything more than a minimal filesystem. But you could use any of a zillion other techniques too. It's a specious point not relevant to this exploit, which certainly cannot have been prevented by SELinux.
[1] Which has to be developed, after all. Simply saying you're "using SELinux" does nothing to prove to me you have no vulnerabilities or mistakes in your rule set.
"Entire host filesystem" is "/" and anything below, right? If your QEMU process is running in a SELinux context, there is no way it could access the "entire host filesystem".
And as your footnote, a mistake in SELinux configuration is highly unlikely. Once your process is running in a context, you have to have an explicit transition to the unconfined context or you have to relabel the "entire host filesystem" with the context of the QEMU process.
With this vulnerability, the app might have escaped the sandbox and added evil stuff to my .bashrc. The SELinux would be totally useless there.
In other circumstances, the damage would be much more localized -- I mean, if you run qemu as daemon, you are likely doing it as non-privileged user anyway, so even regular unix permissions would be effective.