Hello Hugo,
Glad to see another person exploring and enjoying Siren! I've run into similar questions before, so I thought I'd give my input.
The specification says that actions SHOULD (see
here for a precise definition of the term) have a distinct name, but it doesn't completely restrict it. So, there may be totally valid reasons for not having unique names of actions, and changing that from an array to an object removes the ability to have duplicate action names. The only scenario I can think of (which doesn't preclude others) that might "violate" this requirement is if you interpret the uniqueness constraint to be for an entity
as well as it's sub-entities, but that isn't 100% clear from the spec.
In terms of "easier" access, if you're talking about how much code you have to type, then yeah, an object would be easier.
entity.actions['add-item']
vs.
entity.actions.find(action => action.name === 'add-item')
If you're talking about performance, then that's debatable. With an object, we get constant time (O(1)). With an array, we technically get linear time (O(n)), but we'd need thousands of actions for this to noticeably impact performance. Moreover, if we have that many actions, I would seriously reconsider the design, and I might be more concerned with the network bandwidth than the lookup performance.
In terms of "easier" modification, I'd question why you need to modify a Siren representation. When building out an action, you likely have direct access to it, so whether that becomes part of an object or an array is irrelevant. If you're talking about modifying the fields of an action, then a similar argument can be given. Furthermore, what you're modifying likely isn't the Siren representation itself (a JSON text string). It's probably some internal, parsed representation, so really you're free to use whatever data structures you want at that point. The only thing you need to worry about is the generated Siren representation.
I hope that helps! Feel free to clarify anything I may have misunderstood.