It's inappropriate for RPC protocols.  Nagle's algorithm
attempts to buffer up multiple writes and send them as
a single TCP packet -- where the writes are small.  As
such, it's fine for telnet conversations where you don't
really want each keystroke generating a separate packet
if it can be avoided.  The mechansim is to delay the
transmission of small packets in the hope that more
data will show up.

Consider 9P over TCP.  Many of the messages are quite
small, and will be delayed.  9P is RPC based, so latency
is a big concern.  The sender of the small message is
typically blocked waiting for a response, so Nagle's
hope that more data will be sent is (in this case) invalid.
All is succeeds in doing is drastically increasing the
effective round trip time.

This was a big issue for drawterm.  Use of the mouse
in drawterm results in small Rread messages being
sent, in response to reads of /dev/mouse at the
other end.  These were being delayed by a significant
fraction of a second, resulting in really sluggish
interactive performance, until we figured out that
Nagle's algorithm was responsible and inserted the
appropriate setsockopt call into drawterm.