Part of my standard Visual Studio setup on a fresh install is to add editor guidelines with a guide set at column 80, and to tell Resharper that it should wrap my code at 80 columns as well. In an era of high DPI, super-wide screens why should I adopt a column width that is more suited to the era of teleprinters and pre-GUI green-screen terminals?

Naming

Naming members when you only have a few columns to play with suddenly becomes really important; you can't get away with _incrediblyLongVariableNameLikeThis any more because it uses up a quarter of your available width, even before you start passing it around as a parameter.

Variable names have to be descriptive enough to be useful and unambiguous, but now also have to be concise enough to fit. We all know naming things is difficult, but adding this extra constraint requires that we give it a few cycles more thought.

Indentation and nesting

If every time you have a new scope (be it class, method, delegate, if, while or switch) you lose a tab width (4 characters) then that's 5% of the available width taken straight off. Thus in a conventionally formatted C# class file, you're already losing one tab width each for namespace, module and method; we're at column 12 before we even start writing any implementation.

Complex passages of code (particularly ones that use conditionals like if and switch statements) now carry an overhead in legibility, which is a good thing because too many nested ifs and switches also place a cognitive burden on the reviewer in understanding the code itself.

Inlining

While it can be tempting to achieve some dazzling algorithmic trickery in a single line of code, your colleagues may not be as impressed when you're on holiday and they've got to debug it.

Inlining code is useful in some circumstances but, as ever, too much of a good thing is, by definition too much. Adding a new constraint of column width places just enough of a restriction to force the developer to think about formatting, and not to concatenate so many calls into few lines.

Review

GitHub's default behavior for PR review is to present the diff in a split screen; the existing code on the left, your proposed change on the right. Wrapping code at 80 characters ensures that these two panes sit comfortably side-by-side on a single screen, and that GitHub doesn't have to wrap the code onto extra lines that don't exist in the original file. This is a great help when I review diffs as it's immediately obvious what has been added or modified, and my eye doesn't have to take in additional lines in order to understand the full statement.

In summary, this is why I think formatting your code to wrap at 80 columns gives you just enough of a constraint to work within, with the result being code that is easier to review and understand.