Personally, I agree with the author and generally have argued against hard line-length limits. Today's computers have different screen characteristics than even 15 years ago and we're at a much greater loss of vertical length than horizontal length so it bugs me when I pull up code that has less-readable statements broken apart over ten lines, doing one thing, and leaving 80% of my screen empty when readability would have been improved by leaving parts of those ten lines on a single line.
I can understand the benefits, though, to having sane rules around "how much can go in one line", I just think the overall width of a line is of way lower importance than breaking things up into logical parts -- especially in C# in code that avoids LINQ statements[1] where method chaining can result in some extremely wide, difficult to parse, code. I write almost all of my software on a Widescreen 1080P display where vertical real-estate is vastly lacking and horizontal real-estate is greatly underutilized. I use a pragmatic approach over artificial hard barriers and the assumption that I'll be using my display to look at code the way I do 99% of the time - one or two code files on screen at a time (but almost always a single code file).
My code still tends to mostly prefer vertical orientation. I use these simple rules:
(1) Avoid same-line chaining (Even "ToList" or "ToArray" gets its own line). Line up the dots of the calls with the previous line's dot to make it easy to see it's a part of a chain. This results in "wider" code but makes that code able to be parsed quickly while not wasting vertical space.
(2) Avoid more than one statement per line (conditionals excluded where readability requires -- doing if (isThis && isThat && string1==string2 && string3==string4) would put the two string comparisons on two separate lines usually).
(3) Omit (yes, omit) braces for single statements that don't have indented single statements below them. This gets me yelled at sometimes, but my IDE enforces code formatting for me, so the drawbacks of "accidentally having a statement appear to apply to a conditional that it doesn't" don't happen and with the lack of newlines-for-newlines'-sake in my code, code that's indented for branched statements is easily discernible from code that has a newline due to chaining or some other reason.
(4) Break the rules if readability is improved and avoid religious wars.
At the end of the day, I can live with nearly any code formatting ruleset. I read code more than I write it and I end up reading code that follows a large variety of rules so I try not to be a pain in the ass about it. If I haven't been the most substantial contributor to a project, I follow the other person's rules. If I have, I hope that they'll follow mine. The result has been few, if any, arguments over "tabs vs. spaces" theology.
[1] I have never liked the LINQ statement format as I find it hard to follow "What's Being Done" so I have, with rare exception, stuck with method chains.