They are reliable through exhaustive testing of components, plus error-checking, plus redundancy (on some models). What channels get you is high I/O throughput. Especially in 80 character long records
The machines (were and maybe still) are optimized to run COBOL, and what COBOL programs are commonly used for is operations like "Read a record, use columns 50 thru 59 to add to a total, repeat until EOF. Then print the total formatted as $**9,999.99" So the faster you can read records in, the better.
Channels also did buffering when reading from devices like tape drives that did not like to start/stop their motion a lot. So the channel controller would tell the tape drive to read "a few" records and hold them for when the CPU asked for them. Mechanically, the tape reel would slow to a stop and a vacuum column would hold excess tape. The inertia of the reel did not allow for sudden starts/stops and if you tried you'd snap the tape. Curious Marc has a video:
In 360 a channel could connect to a number of control units that each connected to a number of devices. Early on, just one IO could run on a channel; so all other devices were locked out until the IO was performed (several details omitted).
Early disk IO held the channel until the desired record came under the head. That was after the arm was positioned. 370 brought in rotational position sensing allowing other disk IO to take place.
Later on, tapes also accommodated record positioning. Forward Space File came with 360.
Remember though that these days tapes are often archived in a virtual tape library physically on disk, but processed with tape channel commands.
Back in 360,control units that could handle simultaneous IOs appeared. They were connected to two channels.
The machines (were and maybe still) are optimized to run COBOL, and what COBOL programs are commonly used for is operations like "Read a record, use columns 50 thru 59 to add to a total, repeat until EOF. Then print the total formatted as $**9,999.99" So the faster you can read records in, the better.
Channels also did buffering when reading from devices like tape drives that did not like to start/stop their motion a lot. So the channel controller would tell the tape drive to read "a few" records and hold them for when the CPU asked for them. Mechanically, the tape reel would slow to a stop and a vacuum column would hold excess tape. The inertia of the reel did not allow for sudden starts/stops and if you tried you'd snap the tape. Curious Marc has a video:
https://www.youtube.com/watch?v=7Lh4CMz_Z6M