Any variable default to read/write, unless it is explicitly listed as read only. That said any variable can also be restricted by access rights (i.e. a user might not have the privilege to write to it.
In some system the alarm originate in an underlining system and all state information is obtained from the underlining system. In others the alarm server might be part of a self contained server and perform value and alarm processing all in one server. In yet other the Alarm states might be calculated in some external process and written to the UA server. All of these cases and even others are possible. The specification defines the behavior of the alarms, not how an alarm being active is determined. Since there can be many variants, we felt that restricting item to read only , could block some implementations. especially since a vendor could set access writes to specific applications or restrict access in other manners.

I'm not see something that needs to be fixed, or do you have more specific spec section that might need updates?

Hi Paul, sorry for being late, somehow the answers come to an email address I use a bit more seldom and I was in a business trip, then in vacation.
Discussing with my colleagues internally, there were several questions following your answer. I have my own answers, but we decided to share them with you. potentially for a more in-depth discussion:

1) The ActiveState is defined by the node set as read/write support. What behaviour is expected from the server in case of a write action? The specification mentions only the value update by server specific action.
2) Fields like the ActiveState can be set to read only access by role/user management. If this is done in conflict to the node set definition, then does the device violate the companion specification?
3) If 2) is not a violation of the companion specification then are only the access rights flexible or can also other node attributes (like browse name or data type) be different to the companion specification?

interesting discussion:
1) the active state is no specified Read/Write settings in the specification - so the server can set them as desired. The nodeset my have a default setting, but any defaults are the result of an SDK or implementation, the specification makes no statements. To me it make no sense for the vast majority of use cases to allow a client to write to the active state (unless the Server is not actually generating the Active state via internal logic). If a write would occur to an active state variable, I would suspect the alarm engine would overwrite it immediately - since it computes the Activestate based on other values.
2) If a companion specification defines a specific set of roles for a specific set of actions, then it would depend on the wording of the specification if any changes would be allowed or would result in a non-compliant implementation. most specification do not make statement about roles, since role are understood to be generally a site specific assignment. If statement are made in general they allow for extension (like saying recommended that it be restricted to ConfigurationAdmin) - also it is always allowed to create subtype of a role and move assignments to these subtypes i.e. I have a ConfigurationAdmin role, but I need a ConfigurationAdminUnit1 and a ConfigurationAdminUnit2 - if either of these sub-roles are used they would not violate any statement in a specification.
3) again changing a browse name defined in a type is not allowed. A datatype could be made more specific (Number to Int32, or Integer to Int16), but can not be changed in other manners. But these changes would be for instances (or in Subtypes). The typedefinition always must match what was provided in a specification.

If you have not other actual issue - I would propose this issue be closed as a no fix?

Actually, if you check the OPC UA core objects nodeset, one notices that for ActiveState stands: CurrentRead, CurrentWrite for AccessLevel. Now, we know that the 'new' tables template, in UA specs, does not cover anymore the access level. But still, the question could be if it is as you say: 'To me it make no sense for the vast majority of use cases to allow a client to write to the active state (unless the Server is not actually generating the Active state via internal logic). If a write would occur to an active state variable, I would suspect the alarm engine would overwrite it immediately - since it computes the Activestate based on other values.', then why would the CurrentWrite still be present in the AccessLevel, if anyway the Server overwrites it?
Somehow, it would make sense to combine it with Retain or SupportsFileteredRetain, so that one makes sure the client says to the Server to not update a given Condition and that respective Client can then modify the ActiveState without risking the Server to change it back again. The use case could be needed for some commissioning when someone wants to check the Alarm System of a plant reacting to a given triggered alarm.