My "main" org file is 21k lines, it's no problem at all. My laptop is from 2017 or something.
I do sometimes work on files that are 300k lines (don't ask), and while it's mostly fine, once in a while I'll try to use some less common operation that's not very optimized and have to abort it (e.g. don't try to magit-blame that file). But stuff like searching, scrolling, editing, syntax highlighting are all fast.
If I have to open files >100M I sometimes open them in `fundamental-mode`, which turns off syntax highlighting.
For truly large files (gigabytes), there is the `vlf` (Very Large File) package, which doesn't load it all into memory at once, but still lets you search, scroll and even M-x occur (sort of like grep, but more integrated and editable).
Note that this is on Emacs 31 (there have been some major perf improvements in the last three or so releases, and more is coming with the new garbage collector)
In earlier days there were issues with very long lines; these have partly been mitigated in later releases; on the one hand by faster internals, but also a new builtin package `so-long` that can notice very long lines, default 10k bytes, where Emacs probably should give up syntax highlighting etc. to remain snappy.
I finally made the switch to vim when I was working on a really large frontend template that consisted of the same massive repeated block where a small portion of each was different based on a condition.
There was a lot of search and replace, and emacs started dogging it really hard on like the 10th condition block.
Not these days. Native Compilation made emacs a faster and there have been a lot of other changes. In fundamental-mode, emacs can handle really large files. When opening files literally, it's even faster. I have this 104k line org-mode file and it's reasonably responsive. Reverting it takes a while, but the UI does not hang while the buffer is being formatted according to the mode.
I use a mid tier laptop CPU (6C12T). Emacs is snappy. Compared to what it's like now, it was glacial in 2019.
In general, no... but also maybe yes. It's usually fine, but you may get extra unlucky in specific situations with specific major modes.
I've always found line length the biggest problem. Emacs has never done a fantastic job of handling long lines. If truncated, you can't see most of the content; if not truncated, the performance gets worse with length, and visual-line-mode (essential for dealing with non-truncated long lines IMO) doesn't make it any better.
Performance with large numbers of mostly shortish lines is ok. I've had no serious problems loading 2+ GByte log files (average line length <200 chars) in literal mode. The general performance suggests that Emacs isn't really tuned for editing enormous files, but I've never found things so bad as to be worth switching text editor over.
No, but that’s not really relevant, my point is more that all buffers should be windows across all applications.
Emacs for me gets slow when syntax highlighting is on and I navigate to a very long line, text-mode does not have highlighting or the slowness. Most emacs slowness is caused by bad plugins, which if you report may be fixed by developers.
