Well thought-out question!
I'd go with Method 2, but that's more of a personal preference. To me, the Method 2 Cons aren't much of an issue. I don't see the host OS outgrowing its 5-10GB partition, unless you start installing extra stuff on it, which you really shouldn't. For the sake of simplicity and security, the host OS really should be a bare minimal install, not running anything except the bare minimum needed for administration (e.g. sshd).
The Method 1 Cons aren't really an issue either, IMO. I don't think there would be any extra security risk, since if a rooted VM is somehow able to break out of its partition and infect/damage other partitions, having the host OS on a separate VG might not make any difference. The other two Cons are not something I can speak to from direct experience, but I my gut says that CentOS, LVM, and libvirt are flexible and robust enough not to worry about them.
EDIT - Response to Update 1
These days, the performance hit of virtualization is very low, especially using processors with built in support for it, so I don't think moving a service from a guest VM into the host OS would ever be worth doing. You might get a 10% speed boost by running on the "bare metal", but you would lose the benefits of having a small, tight, secure host OS, and potentially impact the stability of the whole server. Not worth it, IMO.
In light of this, I would still favour Method 2.
Response to Update 2
It seems that the particular way that libvirt assumes storage is layed out is yet another point in favour Method 2. My recommendation is: go with Method 2.
libvirt_lxc populates the guest's /dev tree on startup according to the guest's configuration. The documentation says you have to put the configuration in the guest's XML configuration file. Use a hostdev with the "misc" type and with its source pointing to a char device at /dev/net/tun.
The snippet should look like this:
...
<devices>
...
<hostdev mode='capabilities' type='misc'>
<source>
<char>/dev/net/tun</char>
</source>
</hostdev>
</devices>
...
To edit the guest's XML file use virsh. For a local instance use this command:
virsh -c lxc:/// edit GUESTNAME
I can confirm this working with libvirt-1.2.1.
Best Answer
Doesn't look like libvirt supports the net_cls controller:
"The net_cls is not currently used. Instead traffic filter policies are set directly against individual virtual network interfaces"
Directly copied from http://libvirt.org/cgroups.html