This is approximately the same debate as the one about dedicating entire switches to a network segment, or using VLANs. It really boils down to your comfort level and any surrounding rules, regulations or politics in your particular business. There's always the risk of an elevation exploit within a VM that allows it to 'exit the matrix' and mess with the host system. To date the number of those has been few and the impact minimal.
VMWare's position on this kind of thing is:
The truth is, vulnerabilities and exploits will never completely go away for any enterprise software, but ESX has been remarkably resistant to such issues. If it happens again, we'll find the problem and fix it quickly, as we did for CVE-2009-1244.
My take on this is that running VMs from different network segments on the same hosts is acceptable. I tend to draw the line by dedicating separate physical NIC links and vSwitches for the major zones (a pair of NICs for 'Front Zone' DMZ traffic, and a pair for 'Back Zone' internal traffic). This is matched up with the interfaces hanging off the core firewall so if you have an interface on the firewall dedicated for a particular set of VLANs, you have that same group on a vSwitch in the virtual environment.
As a general rationale, I'm taking a lesson from cloud computing on this one - Many people are comfortable placing workloads, even sensitive ones, into compute clouds like amazon ec2. If you're comfortable with that scenario for the workload in question, why wouldn't you be comfortable with it within your own system? Out in the cloud your client data workloads could be executing right alongside any number of unknown third party's workloads. Within your own system it's always going to be far more controlled than that scenario.
So that's the security take. Ignoring security for a moment, the other big issues are probably around your consolidation ratios, costs and the efficiency of your system. If you're a small to medium shop with only a few hosts, you're going to bite some extra costs by purchasing additional hosts and the surrounding extras (rack space, implementation time, ongoing op costs, licensing costs). If you already have the capacity so that you can run all of your workloads on your existing infrastructure, purchasing additional kit to implement physical separation seems unjustifiable. If you're a big virtual shop, though, the costs involved are probably less significant - You can just take the hosts, licenses and supporting entities that you already own and maintain, and split off a portion of them to run your separate network segments.
I've had real-world experience of pretty much this exact issue not too long ago. For a client project, it was decided that everything needed to be run on physically segregated equipment away from the existing infrastructure. It's proven expensive and problematic to maintain and monitor, and if we were doing it over again I'd stamp my foot to have it hosted within the core infrastructure with appropriate VLAN isolation. We really didn't gain anything beyond perhaps making some non-technical folks happy (which is often important!)