I want to say that the Redfish direction is as follows: - The proposed functions are not intended as admin/operator interfaces, and are specialized for manufacturing usage. Redfish function leans toward users and away from manufacturers) and so in cases like this, to avoid confusing users, Redfish chooses not to change the spec. - The direction is to control access to PUT to the URI specified by the Assembly BinaryDataURI which models the eeprom that contains this data.
However, I don't speak for Redfish and cannot find any public references.
Joe is correct - Redfish is an end-user interface, and so the property-level permissions reflect the functionality that is expected to be exposed to an end user. Users cannot normally change serial numbers, factory-assigned MAC addresses, etc.
But internal to the service implementation, a lot of those properties must be set, either during manufacturing processes, service events, or external data providers. All of those cases are 'out of scope' for Redfish - and so those schema permission rules don't apply.
So while you can't modify the schema to make a read-only property into a read-write property for end users, you can certainly provide an OEM mechanism to enable "factory/service mode" that would allow normally read-only properties to be changed.