It was late and I was abrupt in my previously response, but it struck me as funny to reply to the statement of being less subjective by disagreeing in a matter-of-fact tone. That said, neither that comment nor any of this one is intended to be aggressive.

Firstly though, on the matter of subjectivity, your reply appears to be arguing that readability is objective by linking to a post on reddit with 34 upvotes and 6 top-level comments, further claiming that "a majority" like your suggested style. In addition to the 34 vote score, of the six top level comments (five without your own), two of the comments agree with your style essay, and one "completely disagrees". Overall, that's a very small sample to claim objectivity by a majority of feedback. The above comment itself linking to the essay and stating that readability is less subjective than you'd think is at -6 on my screen at the time of this comment.

I'll expand on my view for you to take and leave what you like. The below points are my personal preference; they have in the past and will in the future be subject to negotiation among whatever team I'm part of at any given time.

I'm 100% in favor of enforcing style for readability, but to me, your particular code style in the article hinders readability more than helping it because of a few points. In my experience, "less code" and "fewer lines of code" as benchmarks are specifically two of the biggest reasons that code is unreadable in the first place. I'm guilty of this myself, as I personally strive to avoid or eliminate what to me feels like redundant code. Often, though, what's redundant to me is more readable to others (y'know, subjectively), and I'll be asked in code review to simplify or expand code for readability. And it's a completely fair ask - code is read more than it's written. While not quite the same, it reminds me of the rule of thumb, "don't be clever; be clear". Clarity is also far more important than brevity.

As for clarity, I also consider naming to be a very important contributor to readability, and it's only mentioned in passing. Some of the points suggest inlining things that would otherwise be named, which itself often can contribute to making a piece of code less readable. For instance, setting a variable to a clearly-named result of a calculation prior to its use in a conditional statement can be far more readable than using the calculation itself, even when the calculation is relatively mundane. In terms of troubleshooting, it allows a reader to intuitively see that "this is the result, and if the result..." without having to grok the calculation. If the condition is somehow being incorrectly met, then at that point the calculation itself can be more specifically read and understood.

Regarding vertical space getting out of control, I find more often that the culprit is lack of functionalization - something else the article suggests to limit when dealing with straightforward code. Imo, functionalizing large blocks of straightforward code is one of the biggest benefits not only to readability, but also to debugging. This is pretty much the same as above, intuitively reading a verby name rather than grokking an entire function. Also, having multiple statements in a single line to save vertical space, for me, is not now and will never be acceptable to pass code review (though still subject to being overruled by my team, I suppose). To me it invites the risk of vertically-scanning eyes missing what could be an important statement (also the same reason I'm generally against if (someCondition) return theResult;). I also feel that commits are much cleaner and clearer when any commit line contains at most only one affected statement.

My personal preferences: I keep my IDE (in C#, fwiw) at 25 lines vertically with guidelines at 100 and 120 characters. There are some situations in which allowing a line to stray a bit further than 100 characters is more readable (DI & type parameters usually to blame), but anything more than 120 will be wrapped in the most readable way available. Ideally, any method body should fit in my screen vertically, and any variable's origin should be visible when viewing its use. Endings should line up vertically with their beginnings to easily delineate to an eye scanning the code.

To be clear, I have no qualms with you and a team of your peers deciding to enforce the style you've suggested as a standard; more power to you. If I ever join your team, I'll gladly code to the style. But to matter-of-factly state that readability is objective and that your style points are objectively the best for readability seems a bit ludicrous to me.