Since in most cases, most lines don't even reach 80 characters, or they're long enough to still wrap at 120, there's not a lot of optimization going on.
Going from 80 to 120 will net you, what -- an extra 2 or 4 lines in your viewport?
It's not worth the optimization when you lose so much for the reasons I described.
If I wanted extra lines, I'd probably use my monitors in tall mode. I mainly just don't want to think about line wrapping at all, that's the optimization for me.
I also tend to work on a single file at a time versus trying to view multiple files side by side. But when I do want to do that, I'm not trying to work on a laptop monitor, so I have 2 monitors for that use case.
The white space I have available but typically don't use, simply doesn't bother me. I like some white space, I'm not seeking out density as some productivity hack, I can tab to another file when I want to see it, seeing them both at same time isn't a huge requirement of mine.
It sounds like you have a job that has you frequently doing code jams on a tiny monitor (why? you got pulled into someone's office? you coding on a train?) so this works for your normal situations. You're not understanding that I avoid those situations. I code from a desk with a full setup or I don't code, I take notes about what changes need to be done when I get back to coding.
Lots of people are using split screen editors though. Tbh if you are butting up against the 120 limit, you're probably doing something wrong and could easily break the lines, or use less levels of indentation.
Over 120 and most likely something is wrong with the code. That many levels of indentation usually means that code's cyclomatic complexity is off the charts and is in desperate need of refactoring. It could indicate bad naming practices (to long) which also should trigger refactoring. This is all to say it is more about what long lines say about the code than anything to do with the display.
Some languages are just naturally worse at this (eg. Java), so there is always some flexibility. But for most languages that don't have multiple levels of indentation by default and the custom of overly long names, 120 is more than enough to be a good guidepost.
I just bought an ultrawide, and I just checked to see how wide my lines are in my code editor. 350 characters.
When I'm coding for myself, I use all of that at times. I love that there are some things I no longer have to break onto multiple lines any longer.
Also, if you have a ton of nested loops etc, then you don't end up with that problem where you can only see the first few characters of the deepest lines.
I think the issue with a very long line is akin to writing without punctuation because code is usually much more information dense than prose it becomes hard to follow what it is supposed to mean than if there were pauses for you to consider points in isolation but otherwise I don't see a problem with long lines if you have for example some very long silly OOP getter chain which is essentially one expression as for tons of nested blocks the general argument is it's a hint that your single unit of base indentation is doing too much and there is possibly something to be done about it though like everything it is usually taken to a unhelpful extreme.
You want to be able to do side-by-side diffs on your laptop using a normal sized (not tiny) font.
You want to be able to paste snippets into design documents and emails and blogs without accidental wrapping or truncating or scrolling.
80 is nicely legible. It works really well.