Protocols will run as the user of the HTTPD service. So if this service is running as "Local System" which is the default, any protocols will also run as "Local System". This is fine as long as you don't have any special security concerns or as long as your protocols don't need to access any resources external to the PP Server.
The most common problem is that you have a protocol that needs access to a file on another server than the PP Server. This might for example be a file located on a network share. The PP Server's "Local System" account is not known to the network share and hence the protocol will not get access to the required file. By running the HTTPD service under a service account, you can grant the required permissions to this account and the protocol can then access the file it needs.
If your PP 2017 R2 Server is using Domain Authentication, you also have the option of using impersonation. With impersonation enabled, a server can run protocols under the client’s user account instead of the server account. Clients can then use their network security credentials, instead of the server account credentials, to access network resources with exactly the privileges assigned to their user's account.
If your PP 2017 R2 Server is using Foundation Authentication, impersonation will not work and then you need to use a service account for the HTTPD service to be able to access external resources.
With the upcoming 2018 release, the plan is to support impersonation also when using Foundation Authentication on Windows. The Hub must then be configured to share credentials for the duration on the session and Impersonation must be set to Full or Restricted in the Pipeline Pilot authentication settings.