Running a service as Local System is bad because it has powerful access to local resources, and Network Service should be used if possible.
After some research, I have found that from the perspective of a remote service, a local service running as Local System and Network Service behaves the same. It is because the local service running as Local System or Network Service is authenticated as machine account to remote services. Therefore, while Network Service is great for protecting local resources, it does not protect remote resources.
Locally Network Service has the same privileges as Local Users. It may not have local access to cert store and other high-privilege items. To complicate matters further, this situation is different if the service is on an AD. If a service is away from AD, it will authenticate as the machine account and have access to AD data. However if the service is running on AD, it will be Local Users which does not have access to AD data by default. For services that need to support deployments on both AD and non-AD, it may make sense to use Local System with a minor tweak.
For a compromise, a service running as Local System can be stripped of high privileges from its token, including SE_BACKUP_NAME, SE_RESTORE_NAME, SE_DEBUG_NAME, and SE_TCB_NAME. That should be a medium ground between Network Service and Local System if Network Service cannot be used.
1. Use Network Service if possible
2. Use Local System and strip SE_BACKUP_NAME, SE_RESTORE_NAME, SE_DEBUG_NAME, and SE_TCB_NAME privileges from its token. Remove more privileges if possible