If you use LVM, you absolutely CAN resize ext2/3 filesystems. You can grow filesystems online, but shrinking them requires them to be offline.
If you configure all your filesystems (except /boot) using LVM, you can simply say lvresize -L +1G /dev/vgname/lvname, then use resize2fs /dev/vgname/lvname to do the filesystem resizing.
Check out the LVM page on Wikipedia and you'll see what it can do.
EDITED: Noted that shrinking requires taking the filesystem offline.
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.
Best Answer
If a filesystem has already been initialised on the new LV then you're probably hosed, because data will have been overwritten. You can still try to recover it, but I wouldn't be too hopeful. If a filesystem hasn't been initialised then it's theoretically possible to recover it (but I haven't tried this myself).
Firstly, make a backup of the entire drive, you'll need it in case the recovery goes wrong. The next step is to try find the LVM metadata backups which LVM creates in
/etc/lvm/archivebefore making changes. If the root volume isn't accessible you can try runninge2fsckto get it mountable, and hope that the backup files were stored near the beginning of the volume. If you do this you'll want to continue recovery from before you rane2fsck(i.e. restore from the backup after getting the backup files).If you managed to get a backup file, restore the LVM configuration with vgcfgrestore. If you couldn't get a backup file you're just going to have to hope that the initial volume was completely sequential. Remove the new LV and then extend the old LV to its original size.
Once you've got the old LV back to the correct size, cross your fingers and run
e2fsck. And you really need to make that backup first, you're probably not going to get this right on the first attempt.