Potential Impact of Removing Domain Admin Privileges from a SharePoint Service Account

Removing Domain Admins from that account is the right goal, and Microsoft's guidance for SharePoint is that none of the farm or SQL service accounts should be Domain Admins. There can be an impact, because accounts that have been Domain Admins for years often pick up dependencies nobody remembers. The ones I would check before you change anything:

• SPN registration and Kerberos. When a service account is a Domain Admin, SQL Server and the web applications can register their own SPNs. Without that right, registration quietly fails and clients fall back to NTLM or the double hop breaks. List what is registered with setspn -L spsqladmin, and create the SPNs manually (or give the account the validated write to SPN permission) before the change.
• Active Directory import. If the User Profile Service imports from AD, the import account needs the Replicate Directory Changes permission on the domain, which Domain Admins had implicitly. Give that to the account that does the import, and not to the farm account.
• Rights on the servers. The account needs Log on as a service, and for SQL the usual rights (Perform volume maintenance tasks, Lock pages in memory if you use it). Check them with secpol or the local policy on each server, since a group policy may have been depending on Domain Admins.
• Things outside the services. Look for scheduled tasks, SQL Agent jobs, backup jobs, file share access, linked servers, and Windows services that run as this account on any machine, because those quietly keep working only because of the broad rights.
• Local Administrators on the SQL and SharePoint servers is the next layer to remove, but do it as a second step after the Domain Admins change, so you can tell which change broke something.

A safe way to run it: use one account per role (SQL service, farm, app pools, search crawl, profile sync) as in the SharePoint plan for administrative and service accounts, test on a non-production copy first, make the change in a maintenance window with the rollback being to put the account back in the group, and afterwards restart the services and test a search crawl, a profile sync, a SQL backup and a Kerberos login while watching the ULS logs, the SQL error log and the event logs.