I am leaving my answer for posterity, but it seems that I've failed to answer the user's question. The user seems to be looking for a justification that guides are sending updates about everything, not for the "correct" thing to do.
As indicated by others in the comments, the guides are doing the "dumb" thing because optimizations are generally saved for once you understand the code and the impact of these optimizations. F.E. Frustrum culling is learned after learning how to draw everything on the screen; even though 3/4ths or even 100% of your geometry will not actually be drawn on screen while you move your camera around.
Sending exacting information is actually not only inefficient, but generally bad. The more you correct the client when it is approximating the correct thing, the more you encounter stuttering or other issues that let the client know that some of their information is being dropped. In general you want the experience to be as seamless as possible so that the user feels in control and immersed in the game. Faking it and correcting things only when necessary is generally going to make it seem like they have an excellent connection even when they don't.
An example can be walking in an FPS. If you lose a couple frames worth of information when your connection drops you will notice that you move backwards 10 feet (or w/e.) If instead the server says "well.. they didn't tell me to stop moving, I'm going to keep moving them in this direction" then most of the time when packets are dropped your user will only get a jarring experience IF they are doing something at that exact moment that would alter their Character but instead the predictive model had them do something else. This is generally acceptable as regular lag (your gun didn't fire, you didn't aim correctly, you thought you rounded a corner but didn't, or some other such thing.)
Disclaimer: I haven't implemented this yet, so take it with a grain of salt
I believe this type of this is normally handled by sending "objectives" and not "constant updates." This is to say, if something is told to go to position X, the server is moving that unit towards position X and the client is doing that, but the server has the "truth." The client has an "approximation."
The client and server are running similar code, so in theory things will line up reasonably. Then you simply update things on the client when it matters. Did something fire? Put that projectile oriented correctly on the client. The client should do the right thing in general. Did smething die? Let the client know.
The client only needs an outline of what's changed to update itself and the Server should always have the truth; sending what little information needs to be sent to keep the client on track.
This not only abstracts your clients' ability to cause bad data on the server (as in, the server doesn't care at all about the client other than its inputs) but it also minimizes the data that needs to be sent to and fro.
Let the client estimate what is going on and only correct it as needed. Some things will be off due to dropped packets, lag, etc, in which case you should occasionally correct the client I imagine. Don't worry about giving the exact state of the server (very often.) I suggest looking at Path of Exile for a game that started off having desync issues and has become fairly reliable even on mediocre wifi connections. It looks smooth most of the time and feels pretty good, and I believe most of it is because it's not micromanaging what's happening, but instead it's approximating and correcting things as it goes.
