For me it comes down to three things.
1. Ease of use/organization
2. Performance and scale
3. Reporting
One and three could fall in to one, but the ability to know where to go to look to troubleshoot something is a huge bonus. It provides another key detail and the ability to use a course filter when parsing data. Writing 802.1x vs MAB policy, you can end up with some of the same endpoint flows but under a different method you can avoid having to write more complex rules to avoid conflict. Since ISE is a first match policy flow like an ACL, splitting auth out by 802.1x/mab makes this easier on yourself.
On performance, having individual policy sets for various reasons can prevent ISE From having to parse large lists of policy that don't apply. As a high level example of this, if you have 802.1x and MAB in the same policy set, the 802.1x authentications very likely don't need to be evaluated against MAB policy, or vice versa. You also specify identity stores to be looked at when defining an individual policy set, further reducing lookups we might not need with MAB against an external ID store.
Many large complex deployments even have multiple policy sets for 802.1x and MAB. At the end of it all, each deployments design comes down to the use cases you have to work with, and various segments that might need different treatment.
There is a good outline of designing policy sets/ authorization rules in this Cisco Live presentation.
https://www.ciscolive.com/global/on-demand-library.html?search=ise&search.event=ciscoliveus2019#/session/1551475823491001BB2t
