I have an app in production, developed ~3 years ago, only getting core meteor and dependency upgrades as it is already both feature-complete and stable.
It has 50+ collections, a quite high peek connection count, an admin style backend app and a rather complicated real-time front end app in web, ios and android flavors.
This app has benefited immensely from allow/deny with clever and careful use of it through ongoworks:security (I’m probably one of the first users), simple schema, collection hooks, collection helpers and publish composite which used to be the usual suspects at the time with quite vibrant sub communities of their own.
If the client were to ask for new features today, I’d keep building on the existing infrastructure instead of refactoring allow/deny.
I would imagine the codebase to have been 50% larger (and thus much more unmanageable) had I relied on methods for everything.
I’m not necessarily relying on allow/deny today not because I find it insecure or insufficient for anything, I just have other use cases. But I never considered migrating that one large app to methods, either.
I find the argument around allow/deny not supporting complicated requirements misleading.
I don’t agree with the latest security issue consisting any grounds for questioning allow/deny, either because that could have just as likely come up with any other part of the meteor stack. In fact, there had been other security-related patches on meteor (most recently with the version on node) and nobody considered deprecating them. Imagine someone suggesting deprecation of node just becaue a security issue were identified!
In short, deprecating allow/deny would not only be a disservice to those aforementioned innovative people, but it would also be a questionable turn of Meteor philosophy where backwards compatibility is advertised as a core principle.