There is also nothing harmful or unharmful about the length of a function or the lines of code in a file. Different languages have their opinions on how you should organise your code but none of them can claim to be ‘best practice’.
Go as a language doesn’t favour code split across many small files.
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.
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 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.
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