It's all opinions and "best practice" isn't some objective single rule to uphold.

But generally, best practices are "best" for a reason, some emperical. The machine usually won't care but the humans do. e.g. VS or Jetbrains will simply reject autocompletion if you make a file too big, and if you override the configuration it will slow down your entire IDE. So there is a "hard" soft-limit on how many lines you put in a file.

Same with Line width. Sure, word wrap exists but you do sacrifice ease and speed of readability if you have overly long stretches of code on one line, adding a 2nd dimension to scroll.

Assuming there is a compelling reason for a large file to begin with: with all due respect to VS Code and JetBrains, if the tools chokes because the file is too big, use a better tool.

As for long lines, there is sometimes value in consistently formatting things, even if it makes it somewhat harder to read because the lines run long. For example, it can make similar things all appear in the same column, so it's easy to visually scan down the column to see if something is amiss.

In any case, since soft wrapping has been available for ages, why do you feel the need to reformat the code at all in order to see long lines?

> There is no single canonical suite of best practices.

There kind of is, though. Most software engineering books argue for the same things, from the Mythical Man Month to Clean Architecture.

> Different languages have their opinions on how you should organise your code

In general best practices are discussed in a language-agnostic manner.

Software engineering is context dependent.

Take a look at e.g goto

Using goto in C is normal thing

Using goto in C# web dev will get you a weird look during review

Using goto in C# stdlib dev is viable

So as you see good practices arent just tech dependent, but also product (and many more) dependent