First off, the IMP to host interface was a parallel hardware interface. Each type of computer attached to an IMP had to have a custom-designed interface unit that connected to the computer's own I/O system. The effect was that the IMP appeared to each host computer as a reliable I/O device. Here's the description of the interface unit for the DEC PDP-11.[1]
There were several models of IMPs. There was even a distributed, redundant IMP, called PLURIBUS. That was a strange machine built out of 16 Lockheed SUE minicomputers, with partially shared memory. BBN put that together. That was the beginning of network switches bigger than one CPU, but that idea was not used again until the era of big Internet routers about 15 years later.
Links between IMPs had both reliability and flow control. No packet was sent until a receiving buffer was available. So no packets were dropped due to congestion. Not at the link level, and not at the end to end level.
Congestion problems manifested themselves as the network stalling. This was a problem in the early days, but was gradually fixed. There was a fragmentation and reassembly system, which could result in overcommitting buffers. Once someone locked up the entire ARPANET in reassembly lockup by sending a pattern of messages that caused buffer fragmentation.
The obsession with buffer space came from the high cost of memory at the time. It was generally thought that congestion management was about not running out of buffer space. Now we know better. See "bufferbloat".
The IMP to IMP system was trusted within itself. So protocol bugs in the IMP to IMP protocol could cause multiple connections or multiple IMPs to fail.
One of the reasons that IP is unreliable is because that prevents trouble on one stream from messing up other streams. In exchange for less reliability per stream, you get better reliability for the whole system.
[1] http://www.bitsavers.org/pdf/dec/unibus/IMP11-B_Arpanet_Inte...