If the syslog server goes down, then of course the situation is the same as when the indexer goes down.
Point is: indexers will require a restart every once in a while (deploying new config, updating splunk etc.). And that can take a few minutes, causing immediate data loss (especially when sending syslog over UDP).
A separate syslog server can use a lightweight, high performance syslog daemon (rsyslog, syslog-ng) to receive the data and write it to disk. Then you can for instance install a Universal Forwarder on that same box to ingest the data into splunk. That UF can then also auto load balance across all your indexers (in case you have a larger setup with multiple (clustered) indexers). If you send it all directly to an indexer, that indexer will have to deal with all the search load for that data.
The syslog daemon also may require a restart for config changes, but typically syslog daemons restart in a matter of seconds.
For even further improved high availability (and data distribution) you could use a pool of syslog servers and put a load balancer in front of them.
Another massive advantage of using a syslog daemon to first receive the data is that these daemons offer powerful (yet fairly simple) configuration options to recognize where data came from and distinguish different types of syslog data and then write that to separate files / folders, which makes it much easier to write splunk input configurations and determine the right host and sourcetype values to set for instance.
