It's a true story, with the names of the guilty withheld.
A good warning tale. VM administrators really need to be aware of where their VMs are running at any time so we can make decisions to make sure workloads are able to continue running.
However, I still recommend running all your VMs on the SAN with the proviso that you make sure you have more than one array and that your important VMs (AD/DNS/DHCP etc.) are strategically placed on different arrays (i.e. don't have all DCs on the same shelf or same LUN or even same array and so on). Plan for an entire shelf of drives to go dark. Cluster your array controllers and never have just one path to any LUN. Use SAN based replication to other arrays including off site. Invest in storage virtualization which abstracts the underlying SAN hardware so that you have the most options and flexibility to add, move or change the underlying SAN architecture. It's the best of both worlds.
Those are some of the best practices for running VMs on the SAN.
I will say that with any company I've done work with with, I've never seen a "single SAN" or even a single array. The arrays always come with multiple controllers and switches and for high tier workloads, the arrays are mirrored to a whole other set of arrays and controllers, sometimes at a completely different site. In a properly configured and designed production SAN, it simply would not be possible for the _entire_ SAN (from the host's perspective) to go down-without it being a major site outage, in which case you have bigger issues than just your VMs going down or becoming isolated. In that case, that's where your SAN based replication or mirror to a secondary site will come into play, including your vSphere stretch cluster and HA.
If you can't have this level of redundancy in your SAN or you have only one array, then it is better to keep some parts of an application either physical or on a local disk of a host, like a DC or DNS server.