Opens up the question that if you have "messages" are you a stream anymore? Can your stream of messages start mid message for example? Surely a stream can have this happen. Or are you instead messages send over a stream. In which case abstraction of stream instead of reliable message transportation is bit weird.
Wouldn't each input be a single albeit too short message? But this level of granularity really makes little sense...
If you have a reliable-byte-stream abstraction, you only need to add a way to serialise your messages into bytes, and you get a reliable-messages-in-order abstraction for 'free'. That's convenient! And you don't need to teach your lower level protocols about where your higher level messages start and end.
You can also stick your higher level messages into a structure that's more complicated than a stream, eg you can stick them into a tree. Anything you can serialise, you can send.
Of course, the downside to this is that when you don't need these strong guarantees, you are paying for stuff you don't need.
For most applications some re-orderings of messages don't matter, and others would need special handling. So as a one-size-fits-all-(but-badly) abstraction you can use a stream.
> Do we have any actual streaming use of TCP, with purely streaming protocol.
But to give you a proper answer: the stream of keyboard inputs from the user to the server in Telnet (or SSH).