There are some clear warningssugestions in the documentation but very reasonable.
Customizing Start and Stop Behavior with ^%ZSTART and ^%ZSTOP Routines - Design Considerations
Using the ^ZMIRROR Routine
One issue to consider is on Failover or DR mirrors the code might need to be in ZMIRROR not ZSTART.

I don't think you need more than normal production code awareness.

An easy way is setup Operating System–Based Authentication
in %sys
12) System parameter setup
2) Edit authentication options
Allow O/S authentication? Yes   

This allows scripts like this

iris session ${INST} -U %sys << EOF

w "stopping the mirror 1 is sucess: " zw ##class(SYS.Mirror).StopMirror("MIRROR") h
Once an IRIS LDAP account exists it does not appear to be different local account.

You can do this too:
iris session [instance] -U [namespace] tag^routine

Yes there is a way since I have seen it.

The ZLOAD and ZREMOVE commands are combined. Here is a sample I was sent.

showAdmins() n rs1,rs2,rc1,rc2,$NAMESPACE,user,adminrole,roles
  s rs1=##class(%ResultSet).%New("Security.Roles:List")
  d rs1.Execute("*","%Admin_Manage:U,%Admin_Operate:U,%Admin_Secure:U")
  f  s rc1=rs1.Next() q:rc1=0  d
  . s adminrole=rs1.Data("Name")
  . s rs2=##class(%ResultSet).%New("Security.Users:List")
  . d rs2.Execute("*",adminrole)
  . f  s rc2=rs2.Next() q:rc2=0  w rs2.Data("Name"),"|",rs2.Data("Roles"),!
d showAdmins

The host, storage and DB engine don't influence the gref count at all. Only what the code does.
If you do a set,kill or write that is a gref.
The host, storage and DB engine determine the limit of grefs per second.
Faster storage is always better.
More memory (larger global/routine buffer) is always better.
Faster cores are always better. More cores are better if there is work for them to do.
Newer versions of IRIS (DB engine) are always better.

GLOSTAT will give you some numbers

Vertical Scaling IRIS