I don't disagree, which is why I mentioned interest management and viewable sets, and further up, mentioned how the gameplay itself cleverly reduces the scope you need to actually see!
That being said, these games have very little customization, so updating 100 players about 100 players is totally doable at a 30 Hz network tick rate. Keeping everybody updated about all possible changes to the environment, if you have lots of clutter, loose rocks, doors/windows whose state matter, etc, is a harder, and is where the various methods come in.
Simple math: Player position/orientation/velocity/aim/health/ammo/display-bits update size might be about 8+3+6+4+(about 7) bytes, for 28 bytes per player per packet. This means each player needs to receive 28*100 bytes per packet, and 28*100*30 bytes per second. Nothing scary about that these days. Similarly, the server needs to send 28*100*100 bytes per network tick, which is a little more, but a simple gigabit connection is more than sufficient to funnel that out. (<9 MB per second including packet overhead, so you might even squeeze it into a 100 Mbit connection, but why would you? ?)
If the players host the server, yeah, no, that won't work so well. If you try to do this using peer-to-peer instead of client/server, then N-squared at each player will be a problem, both in and out. And if you do the math, 72 Mbit/s cannot support a player count of 100 streaming in 1080p using video streaming, so the bandwidth consumption (for the server, and for each individual player) would actually go up with the cloud-render-gaming approach.
Do you get even better results when applying more smarts? Absolutely!