Set SPN Service principle name for SQL Server Service account - Best practice

I am looking for guidance on Microsoft recommended best practice regarding setting the SPN for the service account that runs the SQL Server service (MSSSQLSERVER) When setting up a new server (or changing the service account on an existing server) should I always explicitly set the SPN (even if the server has no linked servers defined) or should it only be set in cases where you experience issues such as a double hop authentication issues when using a linked server? I want to set the SPN for every service account that runs SQL and our security/AD person only wants to set it for those servers where a linked server is defined. Is there a downside or security risk in setting SPN if you don't have linked servers. This question applies to SQL 2012, 2014 and 2016. I have found a few links that seem to suggest that setting the SPN explicitly should be the best practice so that Kerberos authentication (SQL's first choice) can be used rather than having to fall back to Windows NT Challenge/Response (NTLM) authentication Some articles that seem to suggest setting it should always be done - FAQS around Kerberos and SQL - Security Considerations for a SQL Server Installation - Resolving Connectivity Errors - SQL Server Kerberos and SPN Quick Reference