This proposal doesn't simply provide a simpler alternative to existing API, it adds new functionality to StreamMessage. StreamMessage doesn't currently have methods to return objects of any of these four types, so the first thing to consider is whether we would want to add four new methods to StreamMessage to return an InputStream, OutputStream, Reader and Writer.
The StreamMessage object has methods which make it look like a stream, but it doesn't actually have any methods to return the stream directly. This was probably deliberate as it didn't force the implementer to use a stream internally. We need to consider carefully whether exposing the underlying stream (or perhaps forcing the implementation to create one if it doesn't use one internally) might cause problems for implementers.
The classes Reader and Writer are for character streams only, whereas a StreamMessage can hold a stream of different object types. I'm not sure that's a good match.
As for InputStream or OutputStream: I wonder whether returning an ObjectInputStream or ObjectOutputStream would be more appropriate, since these stream types, like StreamMessage, have specific methods to read and write various primitives such as boolean or long rather than simply bytes. However the methods it allows are not identical to the methods on StreamMessage (e.g. StreamMessage defines its own rules on type conversion). I wonder whether the differences would cause difficulties.
You use the word "conversions". Currently #getBody doesn't perform type conversions. There is currently a one-to-one mapping between the message type and the class that must be passed in. For example you can't use call getBody(byte.class) on a TextMessage to obtain the text string as an array of bytes. But if we allow the body of a StreamMessage to be returned as (say) a OutputStream, do we also need to allow the same for other message types such as BytesMessage or TextMessage?