Piggy-backing on what's already been said here:

Introduce your users to The Principle of Least Privilege. It's a security principle that says you give the users the rights they need and no more. Now, if an end user can justify needing be able to create databases, manage security on the server, shutdown the SQL Server, etc., then they get the appropriate rights. They can't. You should be able to get backing from your security personnel or auditors if you're in a large enough organization.

Show them the tons of documentation which all state "Don't use the sa account, ever." This is a well known security practice not to use. You can rename and you can disable, but as Steve says, you'll likely get into trouble later. I've written a blog post about a security company that requires it for one of their security products, okay, a rant, but generally, this is a no-brainer.

As previously said, set a strong password. Use a password generator to ensure it is complex and long. 20 characters or more. Make two copies of the password. One sealed and stored on-site in the event of an emergency and one sealed and stoerd off-site with your backups in the event of a disaster. Do this even if you can go to Windows authentication only mode. It's a simple registry change to flip it to mixed mode and then the next time the service restarts, such as when the server reboots due to security patches, you're in mixed mode.

If possible, switch to Windows authentication only mode. SQL Server logins have known weaknesses travelling across the wire and besides, if you can go to Windows auth mode, that means you have one source for security: Active Directory.