1) OPSREPLY Delay(n) is an unconditional wait - no reply will be attempted until the specified seconds have elapsed; Wait(n) is a conditional wait in that OPSREPLY checks each second for a matching WTOR, when found the reply occurs, if after the number of seconds expires and no matching WTOR is found then a bad RC is issued.
a) just the OPSREPLY with the DELAY- - each OPSREPLY command is unique.
b) see above response on how OPSREPLY WAIT works, but the REXX exec will not continue to the next instruction until OPSREPLY is done.
2) SYSWAIT keyword - (Optional) For a cross-system request, the SYSWAIT keyword specifies the number of seconds that CA OPS/MVS should wait for the remote system to receive and respond to the request. The default is the value of the MSFSYSWAIT parameter; you can specify any number of seconds from 1 to 600.
3) Either way of coding will work - if this is issued from a MSG rule NOOUTPUT is assumed; as a good coding practice you should specify the complete syntax of keywords in place of the accepted abbreviations. And your example did not include msg.replyid, be careful to not create a local variable with the stem name of an OPS/MVS event variable - do not use a local var of replyid as event variable name msg.replyid would be changed.
4) Use ADDRESS OPER when you are capturing the WTOR, as it is more direct/efficient since the executing code has all the information it needs. Use OPSREPLY after the WTOR/s have been issued if you can not or do not need to when the WTOR is issued. Example - use OPSREPLY when shutting down an application that requires a response/command to a WTOR that is always outstanding, like IDMS or IMS..
Change the message rule to use this statement: ADDRESS OPER "R "msg.replyid",yourintendedreply"