|AD Security Group||SharePoint Group||SharePoint Permission Level|
After creating SharePoint groups and placing AD groups, you can add and remove individual AD user accounts from the AD groups without triggering new crawls. However, to me the main benefit here is about Information Governance: If you have a documented process of requesting, adding, removing, and documenting membership in AD security groups, and if you remove the ability of site "information managers" to add individuals and groups to their SharePoint sites, you can effectively manage information access and security in a way that is auditable and defensible.
Note: The permission level "Manage Information" is not an out of the box permission level. I typically create this permission level and remove the ability to manage permissions and lists. I plan to write more about this in future posts. I also blow away the "Site Owners" group, leaving those permissions to trained site collection administrators. I have seen too many site owners "accidentally" delete entire subsites and lists when they should never have had those rights to begin with. This is better for everyone.
Note: It is usually a good idea to keep Active Directory Security Group object names to no more than 64 characters in length. You need a naming convention that is unambiguous when identifying web applications and site collections as well as permission roles. And document this!
See this post for details about how adding people and groups to SharePoint sites will affect search crawls:
Clarifying Guidance on SharePoint Security Groups versus Active Directory Domain Services Groups