I am a strong proponent of RBAC -- managing roles effectively does an awful lot more for your enterprise than Active Directory groups.  However, you still need AD groups to be managed.  And, in my opinion, no IT admin should ever have to manage these groups.  What you can't automate then delegate.

Active Directory groups are essential for fileshare permissions, for email communications, a few GPOs, and just plain useful for some application permissions.  You can use them for SharePoint, though I recommend you utilize roles for that as well.  Either way, you still need to manage them without taking up your entire day adding and removing members from AD groups.

To keep from investing a full time person managing AD group membership, you need to do two things: 1) create dynamically maintained groups and 2) offer self service to your users to manage their groups.

Dynamic AD groups are exactly what they sound like.  You write a simple (or complex) query that can read attributes in Active Directory or your HRIS or some database with useful identity information.  Your group memberships dynamically change whenever any of this identity information changes. 

You will need dynamic groups for security groups and distribution groups.  Don't fall for the Exchange QBDL trap...you cannot manage permissions with those.  An application like EmpowerID Group Manager has an exceedingly simple interface to manage these dynamic groups for both security groups and DLs.

The only complication is GIGO, you need to ensure that your identity stores are accurate.  Having a metadirectory constantly inventorying these data stores will ensure accurate information on your users and keep the dynamic AD groups accurate.

Now for the fun part...delegating group management to your users.  Obviously, do not do this without solid workflow controls in place.  You will have group owners managing membership in their groups, this is usually a pretty solid practice.  If you trust them to own the group, you can trust them to manage the group membership.

But the piece you want to add to this equation is group membership attestation.  Either for regulatory or token bloat reasons, make the group owner attest to the membership and existence of this group periodically (bi-yearly for example).  If they don't need it, de-activate the group.  If the member should no longer be in the group, remove them.

There are also groups that your users know they want to join.  Give them a self service portal for joining or leaving groups.  Put workflow on it so that approvals are needed either from rules or approvals.  Make some groups unjoinable (such as the 10K report team) and some wide open (like the book club).  For the rest, have the owner approve membership or allow anyone within a certain division of the company to join it but disallow others.

Which brings us to separation of duties.  Make sure that separation of duties are enforced with AD groups the same way they are with roles.  If your users is on the investment banking side of the house, they should not be able to join any groups in retail banking.  If they are in the invoice approval group, they cannot be in the sign a check group.  These SOD rules have to be built into Active Directory group management the same way they are in your RBAC rules.

It is pretty clear that AD group management is important.  It is also a vital part of your IAM strategy.  If the need is to knock off one piece of ROI-producing identity management quickly, consider group management.  Just think of all of your helpdesk time spent keeping those groups accurate.  Take that money saved and move on to RBAC managing ALL access and permissions!