#1 is a nice recommendation, but not trivial.
You've got three major systems for detecting policy violations: static analysis, dynamic analysis, and human interaction. You don't want too many false negatives or else you get bad media coverage complaining that you aren't doing enough to enforce policy. You don't want false positives or else you hurt benign users.
Static tooling will be able to detect specific kinds of ways that an app might refuse to work if you don't have a permission, but will struggle mightily in general. Dynamic analysis needs to be driven to the specific feature that triggers the behavior. Both will struggle if the app's response is something like returning to a home screen with a custom message. And good luck teaching one of these systems what "disabling unrelated functionality" looks like.
Human interaction works better but is a gazillion times more expensive. Training people is also harder than one might think. You can train humans to identify "disabling unrelated functionality" but that's fuzzy enough that there are going to be some errors. Doable, but every single new policy costs significant amounts of money.
Policy overload is also a problem for developers. There are already a lot of rules on both app stores. Developers get a new "hey this is a new rule you need to comply with" email all the time. You can only roll things out so fast or developers will get overwhelmed with just validating that their apps remain in compliance.
These are often solvable problems in isolation, but when taken as part of the overall effort of policy enforcement on app stores they become quite a bit more challenging.