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).