The reason you need to call clearProperties() before setting individual properties on a received message is given in section 3.10. "Changing the value of a received message" of the JMS 1.1 spec. This states:
When a message is received, its header field values can be changed; however, its property entries and its body are read-only, as specified in this chapter.
The rationale for the read-only restriction is that it gives JMS Providers more freedom in how they implement the management of received messages. For instance, they may return a message object that references property entries and body values that reside in an internal message buffer rather than being forced to make a copy.
A consumer can modify a received message after calling either the clearBody or clearProperties method to make the body or properties writable. If the consumer modifies a received message, and the message is subsequently redelivered, the redelivered message must be the original, unmodified message (except for headers and properties modified by the JMS provider as a result of the redelivery, such as the JMSRedelivered header and the JMSXDeliveryCount property).
I think that explanation is still valid and so the existing behaviour is justified.
The proposal for a copy constructor is worth considering and will be considered by the expert group for inclusion in the JMS 2.0 early draft. Tagging appropriately.