I don't think there's a need for this. Many providers already offer message compression. The JMS spec deliberately doesn't define the wire format of a message and so providers are free to compress messages in transit if they wish to.
In my view, message compression is best configured using global settings in the provider rather than on a per-message basis. This is because whether message compression is needed for a given message depends on the performance characteristics of the provider itself: there is a trade-off between the extra time needed to compress and decompress a large message and the time saved in sending a smaller message down the wire. This trade-off will vary from provider to provider, and so allowing the application code to directly configure whether a message is compressed would reduce its portability.
A further reason for keeping message compression as a provider-specific configuration option rather than as part of the JMS API is that it allows providers to decide for themselves what configuration options they want to provider. Some providers may not support message compression at all. Others may offer a global switch to allow message compression to be switched on or off. Others may allow message compression to be defined on a per-destination basis. Other may allow the administrator to define a size threshold above which messages will be compressed. Finally, some providers may allow the administrator to configure what compression algorithm is used. I feel this is an area where it is beneficial to allow providers to differ and offer whatever features that they believe provide best performance.