You can't use a reset just because you want to be fast or don't feel like sending any more data. Resets are for something abnormal happening. A timeout isn't abnormal to a TCP connection. It's part of the process.
A TCP connection may terminate in two ways: (1) the normal TCP close sequence using a FIN handshake, and (2) an "abort" in which one or more RST segments are sent and the connection state is immediately discarded.
and
A host MAY implement a "half-duplex" TCP close sequence, so that an application that has called CLOSE cannot continue to read data from the connection. If such a host issues a CLOSE call while received data is still pending in TCP, or if new data is received after CLOSE is called, its TCP SHOULD send a RST to show that data was lost.
So this behavior seems fine unless another RFC specifically prevents it.
It's also a simple and state-free way of influencing other devices on the network. Arbor is an interesting example - when doing DDoS mitigation, an approach which doesn't require a lot of resources or statefulness is extremely useful.
On one hand, I want to agree with you: this is terrible and makes everyone else's life harder.
On the other hand, maybe its TCP's resource requirements that are at fault.
HTTP does not have a way of sending an error in-mid-transfer, so a TCP reset has to suffice. The other option would be to blackhole the connection, but that would be worse for both sides.
That's not correct. Both Content-Length and the chunked encoding scheme would allow the client to know that the connection was terminated before the end of stream was reached.