I worked with serial-based systems in the 80's and don't ever remember parity being useful for anything; it was simply something to get right when you set devices up. The effect of receiving bad parity was device-specific: some devices would simply ignore the character; some would show a character even though received incorrectly; at least one type of dumb terminal I remember printing a funny character (perhaps a tilde ~ ) in place of the incorrectly received character.
The original idea of parity checking was obviously to detect gross errors where 1 of the 8 bits in the character had got flipped in transit (perhaps in noise on a long cable). Obviously, it's of limited use, as a run of bad bits could easily render the parity overall as being correct.
If the 'end-application' is an interactive terminal or printer, you can obviously spot that the characters are corrupt, as a stream of rubbish comes out on the paper or screen. For file-transfer applications, or some kind of serial-based protocol (like the IBRO protocol they used to use in card-swipe terminals), you wouldn't depend on parity, but rather there would be some kind of better checksum. I remember sending frames that consisted of STX + data + ETX + plus a one-byte checksum that was calculated from the data bytes. If the checksum calculation didn't work out the same at the receiver, you would send a NAK, and the sender would send the frame over again. Some similar kind of logic exists in Kermit, IIRC.
You mention tn3270, but this is really on a different timeline to the one you suggest. IBM networks used synchronous links carrying SNA protocol encapsulated in SDLC frames at the low level this data was sent serially but with special start/stop patterns that couldn't appear in the data, and with a 16-bit cyclic redundancy check (CRC) to make sure the data was good at the receiver. The terminal protocol was 3270 (using EBCDIC coding, as you mention), and this was a whole parallel world to ASCII-based PCs with their asynch serial communications. This proprietary world of SNA communications lasted through the 90's until TCP/IP and the Internet ultimately displaced it. The tn3270 that you describe is a way of encapsulating 3270 data into TCP/IP (telnet) packets, as a way to integrate the last few distributed IBM mainframe users into the new world of TCP networks.
CRCs of varying lengths are used in modern communications, as it allows you to detect more than one error in frame, and is a good indication of the frame being overall somehow corrupted. Going further, there are forward error correction systems in use now that allow you to correct a small number of bits in error, as well as detect a frame that is corrupted beyond repair.
More detail about how serial communications works can be found in the data sheets for UART chips. PC designs used chips like the 8250 and 16550, but their modern descendents (like the Maxim MAX3109) have all the same ideas built-in.