One of the reasons ed is so terse is because bandwidth was really expensive back when it was written. Not necessarily in terms of money (since everyone was at a university), but in terms of time.
If your editor were to echo back everything you'd typed, you'd waste twice the bandwidth (once to send a keystroke in and once to get it echoed back). Though in reality it would be more like 4 times because each character sent through would require a TCP-ACK packet sent back. By saying nothing, ed became really fast.
sed took things to the next level. If you already had a file on a remote system, and wanted to make changes to it, all you had to do was note down the 'ed' commands to make those changes, and then tell sed to run them. You didn't have to open ed to operate on the file, you just had to send your commands over the network and sed would operate on the file remotely. A more efficient rsync, if you will.
ed preceded TCP (first ed manual I could find is dated 1971; the first TCP research paper was by Cerf and Kahn in 1974).
When ed was used, it would be common to interact with the computer on a teletype, not even on a crt monitor. So a response meant printing characters on paper.
sed was and is more about programmatic editing (i.e., editing a stream as it was generated, using a script for commands), or editing of large files that would overwhelm system memory, not about some kind of remote usage the way you're describing.
It wasn't network bandwidth actually, it was printing speed. When your terminal can only print ten characters per second, terseness is even more of a virtue than it is on a slow network.
If your editor were to echo back everything you'd typed, you'd waste twice the bandwidth (once to send a keystroke in and once to get it echoed back). Though in reality it would be more like 4 times because each character sent through would require a TCP-ACK packet sent back. By saying nothing, ed became really fast.
sed took things to the next level. If you already had a file on a remote system, and wanted to make changes to it, all you had to do was note down the 'ed' commands to make those changes, and then tell sed to run them. You didn't have to open ed to operate on the file, you just had to send your commands over the network and sed would operate on the file remotely. A more efficient rsync, if you will.