I disagree because reading is just one use case. Sometimes longer lines make it easier to skim because you aren't needing to read everything, just letting your brain pattern match as you move along. In that case it can be better to fit more blocks of text in the viewport.
As Alistair Cockburn said in his excellent post-mortem for his cohort's CASE tool efforts (paraphrasing):
People hate change.
No, seriously, people really hate change.
This mentality is exactly why UX designers suck. It's all about some developers forcing their weird vision on everyone with no regard for user choice even when it wouldn't cost much to include because X study claimed something.
I bring this up because recent studies have managed to account for the saccade error associated with return sweeps and have found that reducing said error does not increase reading speed or comprehension.
https://link.springer.com/article/10.3758/s13414-019-01742-3
It's also worth noting that studies done on print line length aren't applicable to screen line length, and that most studies deal with lines of 30-100cpl, sometimes up to 130cpl, which isn't enough most websites rendered on a 16:9 screen or even the current Wikipedia design (on my 1080p monitor at least).
* Short lines are exhausting to read because you have to move your eyes more
* Long lines are exhausting to read because you lose track of where the line is
There's no reason for this to be user defined. Just pick a reasonable line width for your given viewport and fill the remaining whitespace with useful information. Wikipedia did this very well and I genuinely do not understand why every top-level comment on HN is bashing the redesign.