With Windows authentication the username and password are never transmitted to the SQL Server. Only the users Kerberos or NTLM token are passed.
With SQL authentication the actual username and password are passed, but they are not passed in clear text. The authentication process is encrypted via SSL with a self signed certificate to ensure that the username and password aren't passed in clear text. This does mean that a man in the middle attack would be possible as the cert isn't generated by a recognized certificate authority. Now if your SQL Server is configured with a certificate that it from a CA then that cert is used for the authentication SSL encryption instead of the self signed cert.
The connection string within the application should be encrypted no matter which authentication method is being used.
Now the nice thing about Windows auth is that the DBA doesn't ever need to know the password for the account. That's all handled by the application. Granted this isn't that big of a deal, I can use execute as to run commands as the application account all day if I so desire.
With a SQL Account the admin who is installing the software can easily enough be the one that sets the password, or changes the password so that it isn't known by the DBA.
Another nice thing about Windows accounts is that you know for sure that the password will meet the company security policies. SQL Passwords can have the policies disabled and the passwords changed then the policies reapplied which means that the password might not meet the required policies.