Well, you often have some dependency between messages. Some re-orderings don't matter, but some do.

If you just keep everything in the same order, then you never have to worry about any re-ordering.

I can see why people picked streams as the one-size-fits-all-(but-badly) abstraction.

Because worse is better and if you try to be everything you (don't) get OSI. Also because everyone loves serial ports and dialup modems and TCP just emulates a serial port over packet network. And it wasn't supposed to be one-size-fits-all, rather «let us have telnet while we figuring out the rest» but then ossification happend.

Is it really that unfortunate? What’s the big downside?

There’s a bit of reinvention needed, sure, but adding a framing layer is about the easiest task in networking. If you want a standard way of doing it, these days you can use a WebSocket.

Edit to add: oh, I see, you want reliable but unordered messages. That would definitely be useful sometimes, but other times you do want ordering. If you don’t need ordering, isn’t that pretty much what QUIC does?

SCTP did both reliable/unreliable and ordered/unordered, with QUIC arguably being at least a bit inspired by it, but going over UDP because internet is broken.

EDIT: Internet being broken is also why there's a grease extension for QUIC

What would ‘reliable but unordered’ even mean? What’s the difference between a dropped message and one that’s just late?

The difference is whether you get to process the ones which came after first or you must wait for the retransmission of the earlier ones. FWIW, SCTP provides for this difference.

> I feel so stupid for never noticing that pretty much everything done on TCP is actually message exchange, not streams.

This generalization isn’t true at all. Streaming data over TCP is extremely common in many applications.

When you download a large file, you’re streaming it to disk, for example.

I guess you could get pedantic and argue that an entire stream of something is actually one large message, but that’s really straining the definitions.

By numbers of communication actions, pretty much everything may actually be a message exchange, but by the amount of data that was transferred for many years the file downloads and uploads had been dominant on the Internet, which are the kind of thing for which TCP has been designed. For a big file more data may be transferred than for thousands or millions of message exchanges.

Nowadays perhaps video streaming, which may be lossy, so TCP is not needed for it (i.e. what is now called streaming does not have the reliability requirements of the TCP streams), might transfer more data on the Internet than file downloads, but that is not a desirable technical evolution, the replacement of downloading with streaming is just a means to extract more money from those who are satisfied by such a service.