As a general rule, a VLAN should span as few switches as possible (ideally each VLAN is only present on one uplink from the Core/Distribution, and its redundant pair), so from a design perspective a VLAN that spans an entire campus isn't particularly desirable from the point of view of risk management in terms of both faults and simplicity of management.
As far as simplicity goes, I find matched pairs of Data/Voice VLANs is effective.
As for QoS, it depends on the requirements as well as the vendor implementation, but if you're simply "Trust"ing the Layer2/Layer3 markings it doesn't really matter how many VLANs you have - each Access switch should only have one Voice VLAN anyway.
If you're having to re-mark the voice traffic, that's done on ingress at the Access level anyway, so you would have the exact same config on every single Access switch regardless of which VLAN it's in, possibly identifying by a different subnet on each Access switch (if that's how your QoS policy finds the relevant traffic).
Multiple VLANs means creating multiple DHCP scopes. Some people might see this as extra work, but managing a bunch of small scopes provides an on-going advantage over managing one single larger scope.