The binaries can live on C:\ or another system drive (though said drive should be formatted using the default block size). My personal preference is to place them on another system drive (again, formatted using the default block size) because of the following reasons:
- The page file, by default, resides on the C:\ drive
- Other processes keep all manner of junk on the C:\ drive, by default (e.g. Windows patches, C:\Temp, etc.)
- SQL Server log files are written to where the binaries are installed, by default
- I'm lazy and don't want to do a whole bunch of post-install reconfiguration, and this also makes it easier for future DBAs to find where the SQL-related log files are located in the event of an outage, etc.
The main point here is that between the page file, patching, etc. the C:\ drive can be utilized by processes outside of your control as a DBA. The problem with keeping the SQL Server log files on the same drive as these other things is that over time this drive can (and generally does) get crowded which can potentially cause a system outage if it becomes full and you can't write to it.
Regardless where you install binaries, I also recommend you make sure the system databases (e.g. master, msdb, model) are located on your data drive. If they're also located on the C:\ drive, they too can contribute to disk crowding with their growth over time. Finally, just make sure the block size for the disks hosting database files (e.g. mdf, ldf, and backup files) are all formatted with 64Kb block size. It's much more of a pain to make this happen after you lay down the binaries than before.
Final note; as pointed out by Aaron Bertrand in the comments, there are still some files that will always be created on the C:\ drive, such as various dlls and the Setup Bootstrap log files. Leave those alone as they are necessary to keep your service running, but for me, moving most of my SQL Server Binaries off of the C:\ drive often proves beneficial in the long run.
