NTLM is a challenge/response type system, and while it has a resonable level of security it is potentially vunerable to attack and credential theft. In fact NTLM V1 is a known attack vector, considered insecure and should be disabled on your systems. NTLM V2 is more secure, and the current standard.
Kerberos handles mutual authentication between parties, ensuring that the tokens are encrypted and secure. I'd recommend reading the Kerberos basic authentication concepts to get a handle on it. The reading is a little dry, but it will give you a greater understanding.
Of the two, Kerberos is far more secure, and is the recommended protocol for Windows connections to SQL Server.
To resolve your SPN problem look for duplicate tickets using SETSPN-L with both the server, and the service account, and look for duplicates. Remove those, and then adjust the SQL Server service account to allow it to self register its service principal name. This will allow it to handle things itself, which makes life a lot easier.
You will not experience any actual problems with SQL (except for times when you might be using linked servers, or some other double hop type scenario where the ticket cannot be passed along to a second machine), and so it may not be a critical fix to you. Only your security team can really define that.