Hi, Matt at Pure here.
Our arrays are A/A from the front-end IO handling perspective (you can round-robin IO across all ports on all controllers, and all LUNs are available on all ports of all controllers), but from a back-end IO handling perspective they are A/P. This was a design choice, so that one controller is capable of handling the IO performance of the entire array, and enables us to perform non-disruptive upgrades without availability or performance loss. Scale-out arrays which leverage A/A controllers suffer a 1/N performance loss when a controller is lost (in a cluster of N controllers). For a 8-controller (4 Brick) deployment that might only be 1/8, but for a common single-brick deployment (2 controllers), that's a 1/2 performance loss.
We encourage rigorous HA testing as part of every PoC. Get 'em in, pull the cables, and see what happens to performance in all failure scenarios. Pull the complete power to the array and see how fast it comes up. There are real differences between the vendor products in HA.