Kermit defaulted to settings that would transmit 8-bit data over 7E1 through a noisy 110 bps channel (not really, but that gives the flavor - though it could do that if asked). Much-maligned because most terminal programs implemented the base case and nothing more, which was awful.

It was not trivial to reconfigure, but if you did, it had very good throughput. And if you had to make an EBCDIC/ASCII translation, it did that well. Kermit always works. That's the point of the protocol. If you want it to be fast, that's up to you. I did not realize this until I met Kermit gurus who taught me.

Entirely possible I don't understand something as I'm not sure what you mean by taking advantage of higher data rates. We're sending data over UART at the max rate that doesn't introduce too many bit errors. Mainly we needed a protocol to correct for the bit errors (by rerequesting data) and I've always used x/y/z modem for that purpose.

I picked Kermit this time because I didn't want to implement x/y/z modem again and had never used Kermit.

This [1] claims Kermit is faster in some instances depending on what features you have enabled.

[1] http://www.columbia.edu/kermit/perf.html