1. This might not be built in a browser. e.g. Hulu or ESPN iOS app. Although any client of the byte stream could implement the "refreshing" protocol on the client, its more work for each client to do.

2. Given this is Cloudflare they are probably trying to find optimal ways to use bandwidth and their edge fleet. Like TV, maybe there will be no "rewind", and each Cloudflare edge server fans out the same "currently live" bytes to all available clients (i.e. shared state across all client connections, rather than independent state for each client connection). Which can't happen if there is a "refresh" event from each client that needs to be synchronized.

3. "refreshing" implies new state, added latency, and a "janky" feel. If "transitioning" is all server side, bytes from the next "episode" can be pipelined before the previous episode is finished and the refresh event has occurred.

    |-Episode A->|
    |-Episode A->|
    |-Episode A->|
    |          <-|
    |     <--Refr|
    |<--Refresh--|
    |->          |
    |de B->      |
    |-Episode B->|
    |-Episode B->|
    |-Episode B->|

Rather than:

    |-Episode   A->|
    |-Episode A/B->|
    |-Episode A/B->|
    |-Episode   B->|
    |-Episode   B->|
    |-Episode B/C->|