You can get away with very simple access control using scopes embedded in a JWT token, but that approach runs out of room pretty quickly [0]
With Aserto, you can write authorization rules that are evaluated for every application request, and reason about the user attributes, the operation, and any resource context that is involved in the authorization decision.
[0] https://www.aserto.com/blog/oauth2-scopes-are-not-permission...
The {subject,relation,object} tuples do provide a convenient way to express an ACL-based system.
Most real-world systems we've encountered tend to have a combination of user-centric and resource-centric aspects to them. With an ABAC-style policy, you can easily enforce relationships like "user X can edit objects in project Y, and can read objects in project Z". In fact, the Aserto policy for Aserto [1] uses this style of authorization, without going "full-tuple".
In fact, for many use-cases, the prospect of creating an ACL for every resource feels like a management nightmare for the folks we've talked to, and they typically have a "resource group" construct or hierarchy that they want to treat the same from an authorization perspective.
Finally, in addition to the user model, Aserto has a resource model, and we're exploring evolving it more towards the tuple approach.
Denormalization has been around since Date/Codd invented 6NF and relational databases, and then we all realized that most applications have to precompute some joins in order to execute in a performant fashion. In SQL Server we used to call them "materialized views".
A separate (difficult) problem is to keep all the tuple data consistent with the data in your store (often these contain duplicate info).