I would boil it down to this:
Network-centric design simply means having 1 bridge-domain per subnet and strives for 1 EPG per BD, so having many small BDs each mapped to a small subnet. So many BDs.
Application-centric design strives for 1 large supernet mapped to 1 BD. So just 1 BD or comparatively very few BDs.
As far as application profiles and endpoint groups:
With a network-centric design, you're probably best off going with 1 app profile per BD, since an EPG lives under an app profile and can be mapped to only 1 BD, if you already have an EPG1 mapped to a BD1 under an app profile, you can't then create another EPG1 in order to map it to a another, different BD2 (and subnet) under that same app profile. But you can do this across separate app profiles, say app profile 1, EPG1 to BD1 and app profile 2, EPG1, to BD2, though they are not the same EPG, they at least have the same names, though this is probably a non-issue in network-centric design, since for clarity in reading the configs, you'll probably want to put the subnets into the EPG names anyway, but it's good to know that you can duplicate EPG names across app profiles for mixed-use subnets if you really want or need to. This would technically be application-centric design but I view it as more of a hybrid in between pure 1BD to 1Subnet to 1EPG network-centric design and the full application-centric design. Or you could add a new vlan subnet to an existing BD, in order to add those new endpoints to the existing EGP. Or you could still add the new subnet under a new BD and new EPG, but group the EPGs under an endpoint security group, which will allow those EPGs to communicate to each other without any contracts, and migrate and apply EPG contracts to the ESG level to allow communication between that EPG group and other EPGs. Again, technically application-centric but to me the lines are blurry.
Some downsides to running network-centric design include smaller subnets that will run out of available IP space, thus needing to create new BDs and new app profiles and vlan pools for those BDs. and if you're using contracts, you'll want to duplicate any existing contracts from the similar older app profile EPGs into the new app profile EPG. You'll also probably run into some firewall problems as they'll probably already block access to the new BD's subnet for whatever access the older BDs have access to. And also sometimes you'll run into weird application dependencies such as the new servers can't cross layer 3 to talk to the older servers, purely out of application limitations, regardless of the network switch configuration.
With an application-centric design, every EPG is in a single BD supernet, so there's no need to worry about which subnet an EPG will map to. You don't need to create new or duplicate EPGs all the time across new and BDs and subnets. You don't need to create lots of app profiles, one per BD. App profiles can be created per application, not per BD. So fewer subnets, BDs, EPGs and app profiles to deal with. Automation is also streamlined since spinning up new enpoints is simplified with not needing to figure out which subnet and BD to use.
Some downsides to application-centric's 1 giant BD subnet are it's alot of work to almost impossible to migrate in legacy subnetted things over from a legacy datacenter, especially things that are being funneled through firewalls to filter traffic or serve as a security choke-point, since that would mean changing all the object IP addressing in the firewall configs to match the new ACI supernet that the hosts will migrate over to, not to mention all the other unknown configs and dependencies in all other deployed commercial applications, custom in-house applications, web filters, IPS, remote management tools, AAA server configs, etc. This is probably why most who plan to migrate old things into ACI deploy ACI in network-centric design vs. application-centric.
