It's one of the sad facts of life that when you design a popular protocol like HTTP/1.1 so that it can do something, but don't actually do anything with it, many implementers drop it.

Many HTTP servers will not allow you to specify precisely where you break chunks; I would expect that the significant majority of slightly higher level interfaces will not allow you to do that, rather handling buffering themselves.

Many HTTP clients will not allow you to read chunks precisely.

And as for the "event" paramter—well, such things are taken care of in RFC 2616 with chunk extensions; it would end up being

    <length of data in hex> ";event=" event-name CRLF data CRLF

e.g. you would replace the following chunk-encoded data (the first and last lines are artefacts of the chunked transfer encoding):

    1d␍␊
    event: poke␍␊
    data: "hey!"␍␊
    ␍␊
    ␍␊

with the following:

    6;event=poke␍␊
    "hey!"␍␊
    ␍␊

Unfortunately, chunk extensions have never really been used, so I dare say they assessed that technique and decided that it was simply going to require too much work. And so we're left with a new protocol on top of HTTP reimplementing precisely what HTTP already did, but which people forgot about, possibly for performance reasons.

Any SSE server almost certainly uses chunked encoding.

Though technically a non-chunked Content-Length-less HTTP/1.0-style response should work too.