There could be a #4 "historically, streaming could use protocols with unreliable delivery and with limited or no retransmission" (which is somewhat related to #1 and #2). For example, there have been media streaming protocols built on UDP rather than TCP, so packets that are lost are not automatically retransmitted. The idea is that for a real-time stream transmission, older frames are no longer considered relevant (as they would not be rendered at all if they were received late), so there is typically no benefit in retransmitting a dropped packet.

That means you could get drop-outs when data gets lost in transmission, but the overall data consumption of the protocol wouldn't go up as a result.

Not all that long ago, this prompted lots of debate about QoS and prioritization and paid prioritization and network neutrality and stuff. People were arguing that media streams needed higher priority on the Internet than downloads (and other asynchronous communications). Effectively, different Internet applications were directly competing with one another, yet they had very different degrees of tolerance to delays, packet reordering, and packet loss. Wouldn't ISPs have to intervene to prioritize some applications over others?

I remember reading from Andrew Odlyzko that this controversy was mostly resolved in an unexpected way: faster-than-realtime streams with buffering (as the network was typically faster overall than what was needed for a given level of media quality, you could use TCP to reliably download frames that were still in the future with respect to what would be played, and then buffer those locally). This is indeed the scenario depicted in this article.

What about actual live events? My impression is that Twitch and YouTube livestreaming are using a 10-30 second delay relative to realtime, specifically to allow for significant buffering on the client, and then using reliable TCP faster-than-realtime downloads of the "near future" of the video content. Since these streams are purely unidirectional, users don't have a way to notice that they're not literally live. (I don't understand how this interacts with the typical ability to start watching almost instantly, with no visible buffering delay, though.)

There's a big difference for bidirectional conversation, like phone calls, because there even tiny delays are extremely psychologically noticeable. It appears that Zoom, for instance, is still using unreliable UDP streams for call content, which allows skips or dropouts, but keeps the latency relatively low so that it feels comparatively more like a face-to-face interactive conversation.