The subscriptions issue is kind of tricky, we have some similar problems elsewhere. The easiest example is:

• user clicks "Subscribe" on an object detail page;
• request goes to the SubscribeController;
• it needs to test if the user is already subscribed;
• it only knows the object PHID.

So it:

• loads the object by PHID using ObjectQuery; and
• calls isAutomaticallySubscribed().

This means that isAutomaticallySubscribed() can't rely on any data which isn't loaded by ObjectQuery. Examples of data like this are project members, Differential reviewers, and auditors.

Some options I can see:

• make ObjectQuery + CursorPagedPolicyAwareQuery aware of subscriptions and add some needDataToFigureOutSubscriptionsLaterOn(true) method. This doesn't feel very good but maybe isn't awful. A major drawback is that third-party applications can't ever do this sort of thing (change the API of the core).
• add a getSubscribersObjectQuery() method to PhabricatorSubscribableInterface, which defaults to returning an ObjectQuery, and have things use that instead of an ObjectQuery. Instead, objects could return a DiffusionCommitQuery or whatever, configured to load the require data. This is pretty messy and complicated, and we'll end up doing re-loads of all data in some cases, and it's not very general.
• make this data load/populate lazily, when the call is made? We've been pretty aggressively removing lazy loads and they're generally not good so I don't love this. However, in the case of projects this is probably actually better at scale (i.e., if a project has 4,000 members, we might actually want to just issue a query for the one user we're trying to check instead of loading all the members). So maybe this is reasonable, and we basically implement the methods as "if the data is attached, check it; otherwise, go run a query". We've solved so many other problems without needing surprise queries issued from deep in the infrastructure that I don't particularly like this, though. This would also issue a bunch of sequential queries if a user was adding like 50 subscribers to something. Maybe this is a case for changing how the API functions (e.g., filterAutomaticallySubscribed(array $phids) which removes autosubs and returns remaining PHIDs, instead of isAutomaticallySubscribed($phid)).

I don't really love any of these and it's not a huge issue to get it wrong (users can just appear in both "Subscribers" and "Reviewers/Auditors") so I'm just kind of ignoring it for now and hoping the answer becomes obvious in the future.