There is quite a difference between JCR-based applications and RDBMS-based applications in terms of access control (ACLs). These differences exist not only in the ACL-handling of the respective storage, but (as a consequence) also in the ACL handling of web apps that are based on JCRs or RDBMSs, respectively.
First, let's look at the repository level. In the JCR model each node possesses ACL settings for reading, deleting, modification, etc. A piece of content (i.e. JCR node) knows by itself which groups of users have which rights. Because the JCR content model is also hierarchical this ACL approach is comparable to the approach taken in (Unix) file systems.
The situation is different in relational databases where access rights are usually scoped by table (or view). The individual content elements (rows in the table) do not posses individual access rights.(*)
The table-level granularity of RDBMS access rights has consequences for RDBMS-based web apps: the db connection is performed as a technical user. This technical user needs to have the necessary rights to access or modify the table required by the application (i.e. the technical user needs to have the cumulative access rights of all web users). As a consequence the web app itself needs to implement the content access rights. Rather than having access control as a feature that is only implemented once (by the infrastructure developer) and tested a million times (with each application) it is a feature that is implemented with each application again and again. Moreover, two or more applications that operate on the same data run the risk of implementing different ACLs.
JCR-based web applications like Sling (or apps that are based on Sling) behave differently: the web user's credentials are used to create a session in the repository. As such the web app does not perform any access control at all, but rather delegates this task to the JCR repository. The obvious advantages are that the app developer is not bothered with implementing access control and that the ACLs are consistent between multiple apps running on the same JCR (you might have two apps already: consider that Jackrabbit and CRX come with a built-in WebDAV server that constitutes a web app in this sense). Again, the JCR-model can be compared to Unix where commands like "ls" or "tail" do not implement their own file access control, but rather inherit the rights of the user that executes them.
Here is an overview of the situation in both cases:
(*) It should be noted that this can be fixed by e.g. implementing triggers or stored procedures. However, in this post I would like to look at the standard out-of-the-box case, i.e. the infrastructure that this infrastructure software actually provides. The application developer should not be burdened with infrastructure development.
There are also 2 use cases where access control at the web app level might make sense:
* the web app accesses more than one datastore
* more than one web apps access one datastore with different requirements to access rights. Yeah, for the same user, been there, done that :).
Furthermore there is always the possibility that static ACLs are not enough (dreaded "junior account manager may only see clients worth less than 1 mio"-use case). This might be designable within the hierarchy, but I would strongly oppose a hierarchy modeled after security requirements.
But despite this: JCRs hierarchical structure is imho a strong advantage for creating concise and simple access rules vs RDBMs systems. Same goes for REST vs. SOAP btw...