Other methods should support comment as well: Suppress, Unsuppress, Reset, ... etc.
The comment paramter can be optional.
It would be fine to define, when conditions in 'interesting state' are generating events with Retain = TRUE.
In that case comments can be added to these events as well.

There is an AddComment method that can be called at any time to add a comment to the alarm. This can be called prior to a shelving method or after the shelving method is invoked, in any case the comment will be stored as part of the event.

Changing the signatures of the methods would be a breaking changes and likely not supported by both client and server applications.

Is there a reason that this method is not sufficient?

The Signature of AddComment has an EventId.
If the condition is in the normal state, it does not have any events. AddComment cannot be used.
However shelving, suppressing can be used on conditions in normal state.
In this case, it is not defined, if the condition should generate an event by RETAIN = TRUE or RETAIN = FALSE.
Or with other words: is the condition in an interesting state or not.
If the event was generated by RETAIN = FALSE, then no comment can be added, either before or after shelving/suppressing.
If the event was generated by RETAIN = TRUE, then comment can be added after shelving/suppressing. (Generating 1 unnecessary event).
After unshelving/usuppressing if the condition is in normal state, then alway RETAIN = FALSE. No comment can be added after unshelving/usuppressing.
Comments may be added before unshelving/usuppressing. But in this case the comment would say e.g: "X.y has the condition unshelved" but the shelved state is still TimedShelved. It is not nice in a historical view.

1.) The first step I guess is to define, when is a condition in an interesting state. At least regarding the OPC UA standard fields.
2.) It should be considered, if AddComment could be called with NULL EventId, to simplify commenting Shelving/Suppressing. unshelving/usuppressing would be still a problem.
3.) Another solution could be to have an AddNextComment method, the would not change any alarm state. On the next user operation the comment would be updated in the state.

Commenting with the current specification is complicated. The above are just some suggestions, that would make commenting easier.

After UA meeting discussion - add optional comment to all method that do not have a comment field - include description that old system might return errors and what behavior a client should have in this case

decision in UA meeting - add a version 2 of all methods that do not support comments, that includes a comment

Agree in call that addition of new method to statemachine is not a breaking change to statemachine

UPdated specification to add all of the required method as version 2

Agreed to changes in telecon.