Simplify Troubleshooting
Like with any technology, troubleshooting will always be required at some point. By creating separate Fabric Access Policy constructs, making changes only to specific types of constructs will be advantageous so that a policy change to one construct will not affect all endpoints. I commonly see Greenfield deployments where customers have all interface policy groups bound to a single AEP bound to a single domain bound to a single VLAN pool. Great it works and most times required for brownfield network-centric migrations, but its messy, applies the same policy for all endpoints to all endpoints and does not allow for scalability. With this approach you are limited to a maximum of 4096 VLAN minus a few restricted VLANs. You will want to make sure that you can properly support the requirements for brownfield network centric migrations but also be able to scale out to hybrid or application-centric operational modes.
Scalability
With ACI, VLANs are not used in the same manner as with traditional networks. Cisco ACI allows for exceeding the limits of 4000 or so VLANs in traditional networks to ~ 16 million VXLANs in ACI. The concept of traditional layer 2 VLAN segmentation and isolation is augmented with Cisco ACI bridge domains. In Cisco ACI, VLANs are used mainly from a classification and attachment standpoint. For example, server WEB01 connects into the ACI fabric using VLAN 100. VLAN 100 is used as a classifier for this EPG.
When you leverage a single AEP with single Domain and single VLAN pool, you are effectively limiting your architecture to these traditional limits. Now if you plan to stay in a network-centric mode forever and are not concerned about management and troubleshooting, then this may suffice. I on the other hand prefer to keep constructs simple yet scalable and future proof for hybrid or application-centric operational modes.