For me, it seems suboptimal.
First, it abuses
__ac_local_roles__ destined to store local roles at the object (used by Plone's sharing functionality). Your solution interferes with this usage.
Second, it does not prevent searches to find those objects. As a consequence, an unpriviledged user can see a (search) summary for those objects and some search hits are in fact not accessible (likely without hint).
If you have a small amount of subscription sets, I would model those sets by Plone (user) groups - and use Plone's "sharing" to associate a respective group with a subhierarchy. You may need a special workflow in addition to avoid that published objects grant
anonymous. A solution along these lines would allow a standard Plone catalog to only return "accessible" objects.
If you cannot model your subscription sets as Plone groups, I would use an extended catalog. The standard Plone catalog uses the index
allowed_roles_and_users to ensure that (by default) it returns only objects for which the searching user as the
View permission. To this end, it internally "and"s the user search with a subsearch based on
allowed_roles_and_users. Your extended catalog would add a new index (maybe
approved_subscribers) and "and" to user searches a subsearch based on this index.
In the first case, no explicit access block should be necessary (unpriviledged users should lack the
View permission). In the second case, a "post authentication hook" could be used to block the access. If your objects do not provide direct access without the use of
File objects can be accessed without
main_template), then a simpler viewlet based approach is possible: the viewlet shows nothing but checks the access rules.