I'm calling this a wishlist item because it is editorial. Still, here's my reasoning:

When I made a JavaScript implementation of the earlier WebSRT parser, I found it quite hard to follow the steps because of how handling of CRLF is sprinkled all over, and even found a spec bug related to it (fixed already). Of course the spec should be precise down to every single byte what should happen, but I'm hoping that could happen with a line-based parser as well.

If it's not obvious, by a line-based parser I mean one which operates on the input and generates lines for a second step. This wouldn't harm streaming, because AFAICT no cues will be output from the parser before CRLF or EOF is encountered anyway.

I dare say this makes it more likely that implementations of WebVTT in high-level languages like JavaScript and Python will actually follow the spec, since operating on lines is quite easier to understand for a format like WebVTT. If you go and look for random SRT parsers, I think you'll find that most work like this. (The ones I've written do anyway.)

The spec is already mostly line-based, I'm just suggesting that the line-splitting be separated out from the rest to improve readability. Do as you will.

Oh yeah, it'd be simple to add line-based comments to such a parser, too.

This would be a lot of risky work for minimal gain, IMHO.

Risky in what sense? There's no existing content or implementations to break.

Risky in the sense that I'm almost certain to screw it up and spend hours spread over many days trying to fix it.

Let me keep this on my radar for a bit longer, in case I come across a stronger rationale for doing this. Currently though I'm leaning towards not changing this. It would be a lot of effort for minimal gain, and the opportunity cost would thus be high.

Comments from the Open Video Conference, with implementors of Opera, Firefox,
Chrome and Safari discussing WebVTT:

At this point of implementation we don't care about this any longer, closing this bug.