>>75
It's not that it blocks until it sees a full line, it's that it guarantees that it will output the full line with a single `write` call, presumably so that it will be returned by a single `read` call to the next program in the pipeline. Which means that those programs rely on a broken stream abstraction: suddenly fragmentation is no longer an implementation detail but an essential side-channel, the stream protocol is transformed into a datagram protocol, in a completely ad-hoc, unreliable way.
The fact that read(1) makes this guarantee does not mean that downstream filters are compelled to rely on it. It is still perfectly sensible to continue writing programs that can handle a partial read(3) for compatibility with older Unix. However if you need to work with a broken program you at least have the option.
I also don't accept that relying on one-write-per-read behavior is necessarily unreliable. If the reader and the writer agree on the format of the data to be exchanged, they can easily structure it in a way that allows its correctness to be verified by the reader. There's no guaranteeing that a bad writer will produce correct-looking input by coincidence, but there's no way to avoid that in all cases anyway.