Dropping the automatically created NT AUTHORITY and NT SERVICE accounts
Before you downvote, here is formal documentation you can reference for a legitimate reason why these accounts would be scripted as you see: STIG Rule SV-53421r2_rule.  These controls are SQL Server version specific, but there are a number of other controls in the more recent versions as well.  If you work for an organization that falls under these controls and also adheres to some of the more stringent ones, such as revoking default Grants given to the public role things can get complicated pretty quickly.

As I have some experience in an environment that falls under these controls, I can say that you can disable/drop both the NT SERVICE\SQLWriter and NT SERVICE\Winmgmt accounts outright, but you need to make sure your SQL Server Service is running under an appropriate service account with sufficient OS level permissions, such as a sufficiently locked down Domain Service Account, or even better, standalone or group Managed Service Accounts.  Again, OS permissions need to be treated with care as this does venture into house-of-cards territory if you don't perform sufficient testing.

As for the NT AUTHORITY\SYSTEM account, this is NOT an account you want to drop if you are going to be running any Availability Groups.  In fact, STIG SV-93835r1_rule mentions that you should keep it with only CONNECT SQL permissions granted by default.  In the event that you have an Availability group, this account will also need to have the following, additional permissions:


ALTER ANY AVAILABILITY GROUP
VIEW SERVER STATE
EXECUTE ON [sys].[sp_server_diagnostics]
EXECUTE ON [sys].[sp_availability_group_command_internal]


These restrictions can be a royal pain, but there are legitimate reasons you would need to limit their use and permission sets.  If you don't fall under these guidelines, do yourself the favor and comment out those steps.

Hope that helps!