Personally, back in the day when L2 domains flowed all over (today with L3 switches, ideally, a set of VLANs should only be known to an individual edge L3 switch, or to one edge L2 switch and its upstream L3 distro/core switch), I loved VTP for keeping VLANs and VLAN names consistent across a VTP domain. Yes, if you're lacking knowledge how to use VTP, or were careless in its usage, it could burn down your network (which I've seen happen [wasn't me, that time, though]).
I agree with both @Dustin Anderson and @Jens Albrecht , what you've posted doesn't provide much confidence in how VTP was previously being used.
If you're doing a switch refresh, perhaps you should also consider a network topology architecture refresh too.
If not, if you continue to use VTP, you might consider moving to VTPv3, as it's designed to avoid most, if not all, the common ways to "accidentally" cause network issues using VTP. It's a major change, though.
If you want to stay with VTP v1 or v2 (few differences between them), undertake to use it correctly (like whatever was done to have VTP devices with different revision numbers!) and "better" (like avoiding using a null VTP domain name and using a VTP password [password, not so much for "security" but to possible insure you've taken the time to configure VTP to join the VTP domain you really intend]).
Regarding VTP pruning, if I remember correctly, if you have something like SW1(VLANs 1,2,3 ports used)<trunk>SW2(VLANs 1,3 ports used), VLAN 2 will be pruned off trunk (although not immediately, VTP has to figure it out). However, again if I remember correctly, if you have something like SW1(VLANs 1,2,3 ports used)<trunk>SW2(VLANs 1,3 ports used)<trunk>SW3(VLANs 1,2,3 ports used), VLAN 2 will still be pruned because the transit switch doesn't assign a port to it.
Within VTP v1 and v2, the only real difference between "client" and "server" modes, the latter allows manual VLAN configuration changes. I.e. an off-net "client", dropped into the VTP domain, with a higher revision number, will change the whole VTP topology to match it!
If you have more than one active VTP server (again, v1 or v2), and changes are being made on both, concurrently, you have a "race" condition concerning how other VTP nodes are updated. I.e. the switches, showing the same revision number, may disagree, and/or one of the server's updates might be completely erased by the other server.
Basically, when you get into how VTP v1 or v2 functions, without using it properly, it's quite easy to mess up your L2 network. (This is why VTP has such a bad rapt. It's not so much it doesn't work as it should but it's very easy [again versions 1 or 2] to cause problems by how you use it.)
BTW, in your PDF, you list most switches as "2960/3750". Generally a 2960 is considered a L2 switch (some models support very limited routing) while the 3750 is a L3 switch (although what L3 protocols it supported, vary much on the IOS feature being used). The 3750 series is also stackable, and some models of the 2960 series are too. I mention this, because even with those very old switches, possibly there was no need to have many L2 switches to VLAN manage, which is what VTP was designed to assist with. I.e. reduce the demand for managing VLANs across lots of L2 switches, and the demand for VTP is diminished.
Lastly, if you don't use VTP, on later implementations, set the mode to "off" rather than "transparent".
