There could be cases in which creation of more that one volume group is advisable: a database server (Oracle) is such a common situation.
As an example, suppose to have a server with 4 disks, the first couple of disks with two RAID 1 arrays (/dev/md1 and /dev/md2) and the second one with one RAID 1 array (/dev/md3).
/dev/md1 will be used "as-is" for boot file system, while /dev/md2 and /dev/md3 will be used each one as a physical disk. They could be allocated to one volume group or two different volume groups.
Volume groups should aggregate disks with similar usage: the first volume group (and so the first RAID array) could hold all "standard" file systems (root, tmp, home, var, usr, opt, …) along with database binaries and also database transaction logs (Redo Logs), while the second volume group (second RAID array) could hold all database datafiles (one logical volume for each datafile if raw devices are used).
This leads to a "logical" separation of data and binaries. Moreover, returning to the Oracle example, by carefully planning the database structures disposition over the two volume groups, if one of the groups suffers any unrecoverable damage, information on the other group is sufficient to rebuild an up-to-date database starting from backup.
On the other hand such a division can lead to problems like wasting space: probably all disks will be the same in size, while it's unlikely that binaries and transaction logs are big as datafiles, so there would be much space wasted in the first volume group.
There could be cases where a "logical" division of data and binaries is not required or advisable, so one volume group would be preferable (ex. Disk space is scarce or valuable).