Design choice about MAX_RLP_BYTES_PER_CHANNEL

[bap2pecs]

I am reading https://github.com/ethereum-optimism/optimism/blob/develop/specs/derivation.md#channel-format and it says

If the decompressed data exceeds the limit, things proceeds as though the channel contained only the first MAX_RLP_BYTES_PER_CHANNEL decompressed bytes.

Isn't it safer to throw and ignore the entire channel if the data exceeds the limit? I am curious to learn why the design choice was not made in this way.

[smartcontracts]

Some responses for you, relayed from a third party:

It was around being able to incrementally pull batches from a channel before the channel was fully closed. We dropped that feature, but it’s still vaguely on the backlog.