As oded mentioned, this common coding standard is a result of the IBM's 1928 80 column punched card format, since many coding standards date back to a time when programs were written on punch cards, one card/line at a time, and even the transition to wider screens didn't alter the fact that code gets harder to read the wider it becomes.
From the wikipedia page on punched cards:
Cultural Impact
- A legacy of the 80 column punched card format is that a display of 80 characters per row was a common choice in the design of character-based terminals. As of November 2011 some character interface defaults, such as the command prompt window's width in Microsoft Windows, remain set at 80 columns and some file formats, such as FITS, still use 80-character card images.
Now the question is, why did IBM chose 80 column cards in 1928, when Herman Hollerith had previously used 24 and 45 column cards?
Although I can't find a definitive answer, I suspect that the choice was based on the typical number of characters per line of typewriters of the time.
Most of the historical typewriters I've seen had a platen width of around 9 inches, which corresponds with the standardisation of paper sizes to around 8"-8.5" wide (see Why is the standard paper size in the U.S. 8 ½" x 11"? and the History of ISO216 A series paper standard).
Add a typical typewriter pitch of 10-12 characters per inch and that would lead to documents with widths of between 72 and 90 characters, depending on the size of the margins.
As such, 80 characters per line would have represented a good compromise between hole pitch (small rectangular vs. larger round holes) and line length, while maintaining the same card size.
Incidentally, not everywhere specifies an 80 character line width in their coding standards. Where I work has a 132 character limit, which corresponds to the width of typical wide line printers of yore, a 12pt landscape A4 printout and the typical line width remaining in an editor window of Eclipse (maximised on a 1920x1200 screen) after Package Explorer and Outline views are taken into account.
Even so, I still prefer 80 character wide code as it it makes it easier to compare three revisions of a file side-by-side without either scrolling sideways (always bad) or wrapping lines (which destroys code formatting). With 80 character wide code, you only need a 240 character wide screen (1920 pixels at 8 pixels per character) to see a full three-way-merge (common ancestor, local branch and remote branch) comfortably on one screen.