In the early days of Active Directory, Microsoft’s de facto standard was to use the .local namespace for AD domains. “De facto” because I don’t think there was any specific documentation or formal statement saying this but all of their examples and labs used it so a lot of organizations setting up Active Directory did so also.
Not sure exactly when, although I’m sure that it’s been many (many) years, but they do now explicitly state not to use .local or any nonregistered domain name for that matter: see Active Directory Domain Naming Considerations (thanks to Rich Milburn for finding this page).
Today, I just found another reason not to use .local: The Apple Bonjour suite of services and supporting protocols use .local for their name resolution. Thus by default, if you try to access an endpoint registered with a .local name suffix on an OSX or iOS device, name resolution will fail. If you don’t know this, the outcome can be quite perplexing because you’ll be able to access the endpoint by its IP Address and nslookup will work properly but accessing the resource by its .local name will fail with a name resolution error. This behavior along with a fairly simple work-around (at least for OSX devices) is described in the Apple knowledge base article If you’re unable to resolve or bind to domains that end in .local.
So what does this have to do with System Center Configuration Manager (ConfigMgr)? Not much unless you are trying to manage your OSX systems using ConfigMgr which is how I stumbled into it. As a side note, if you truly want to manage OSX with ConfigMgr, then check out Parallels Mac Management for Microsoft SCCM; it puts the native OSX management in ConfigMgr to shame but integrates, looks, and acts as if it were built in.