I recommend going with a variation of "Approach #1" - non-hierarchical Roles.
I've worked with similar systems with great success. While at first this approach may appear 'less structured' it is relatively simple and is very flexible; when allowing multiple Roles-per-User and defining rules for aggregating permissions.
Against Hierarchies (for Roles)
Like an 'OO hierarchy', using a role hierarchy leads to a strict substitution-relationship. This makes it harder to define roles based on changing requirements.
For example, maybe there is a future need for an 'Administrator' account which cannot create their own posts. The hierarchy (and the substitution-relationship it has) prevents this without changing the tree structure itself because a "Full Administrator" is-a "Paid User".
Queries against a true hierarchy are more complex in SQL; especially in implementations that do not support recursive queries, like MySQL. Switching to a hierarchy using a nested-set or materialized approach forces an additional structure over just a parent-child relation.
You Just Don't Need It; the more complex software is the harder it is to write and maintain. While hierarchies are very good in certain cases - such as with a Bill of Material or Genealogy or Directory Structure - there is simply not a 'need' in most Role/Group-Permission models.
For (multi) Roles
Roles, without a 'parent type' dependence, function more like 'OO interfaces' - well, maybe Trait composition would be more apt if analogies are to be stretched. The implementation (read: granted Permissions) of each Role can change independent of any other Role making it extremely flexible. And like interfaces, more than one Role can be assigned to a given User/entity.
Queries against a flat User <M-M> Role <M-M> Permission model are much simpler in SQL (with or without recursive support, or additional structure) because there is simply no Role hierarchy to traverse.
Windows ACL Groups (let's ignore nesting groups) work much like Roles; a User belongs to one or more Groups which grants (or denies, but that's a different situation) Permissions.
Have your Cake and Eat it Too
The variation I recommend, and have hinted to above, is to allow aggregation of permissions across Roles. A simple aggregation model is this:
A User has the union of Permissions from all the Roles they are assigned.
(The effective permissions would generally be built during authorization, but without a hierarchy it is also relatively simple to query in SQL.)
Thus the Permissions are bound per Role with little or no overlap, as show in "Approach #2", with this difference: There Is No Hierarchy.
For example, to allow a special administrator who can search for posts (and delete 'bad' posts), one would simply assign the "Basic User" and the "Limited Administrator" Roles1.
Using a non-hierarchical multi-Role capable system allows this cleanly, shrugging off the burden of a hierarchy, while still providing flexible/composable/configurable Role archetypes.
1 This is not a particular good example. In reality the Roles should have different names (eg. "Account Support" or "Content Moderator") and cover different Permission sets; these will likely change over time based on trial and error and flavor-of-the-month business rules.
While I've spoken against a hierarchy for such, in more complex systems there may be a need to allow relationships between Roles, primarily for grouping of such. This relationship should generally be independent of the effective Permissions applied, existing for other managerial purposes.
