So VMware finally got back to me, and I'm not too reassured by their explanation of what happened. After looking through the host logs for four hosts, he came to the conclusion that the SAN switch (Cisco MDS) did not send any SCSI sense code to the hosts when the device alias table was deleted on the switch (resulting in the loss of zoning WWNs and stopping I/Os). Even though two paths were still available to the LUNs, ESXi and hostd were waiting on I/Os from the black hole path. There's no timeout for that particular wait (without a SCSI sense code), so ESXi hangs. Only when we admin shut the FC interfaces to the UCS blades did ESXi get a SCSI code that something was down and utilize the other two active paths.
As I mentioned before, a physical Windows Server 2012 UCS blade gracefully handled the exact same situation without any noticable I/O problems. So that tells me it is possible for the OS to detect such a condition, even without a SCSI sense code from the switch, and use the other two paths.
The short answer is, in this particular failure scenario of the SAN switch, ESXi will hang forever until it gets some type of other feedback that something is wrong. I really can't believe that is by design...shouldn't it have some type of I/O timer and use the other two good paths??