Looking at the specification the definition of the inputArgumentResults implies that this list shall be empty if the OperationLevel StatusCode is Good:
This list is empty unless the operation level result is Bad_InvalidArgument.

During the discussion in todays UA WG call we identified reasons why this requirement makes sense but also use cases which are prohibited by this requirement.
Pro:

• Saves the time on the client to process the list
• Saves the bandwidth of the X StatusCodes in communication
  Contra:
• Information model groups cannot utilize the inputArgumentResults to provide additional information about the inputArguments like a parameter has been ignored, overwritten with another value or other things.
• It requires servers to first prepare the list while processing the InputArguments but then deleting/not using it if everything is Good.

One possible solution would be to change the wording to indicate that a client is only intended to look at the inputArgumentResults if the Operation Level status is not Good but a server is allowed to return a list of Goods if it desires.