What I've read:
When Client 1 moves, it sends its input to the SERVER, the SERVER calculates the position, and then sends the new position back to all connected Clients, including Client 1 where the Client 1 player is drawn in the new position. Wouldn't this create a big amount of latency between the local player of Client 1 and their movements?
Almost. After Client 1 sends its input to the server, Client 1 also calculates its position, and continues advancing the local game state according to the best knowledge it has. This means you generally see no latency at all here - your immediate outcome is the same as if you were playing an offline game. This is called "client-side prediction".
Most of the time (if you're not using a hacked client, and there are no bugs in the game simulation that cause it to run significantly differently on your device versus the server), the server will agree with your simulation output. So when you get your validated position back from the server, it just confirms the simulation you've already been running and displaying in the meantime, and nothing surprising needs to happen.
But sometimes the server knows something you didn't when you sent that input. In actual fact, another player changed course and collided with you a fraction of a second ago, or put an obstacle in your way, or shot you, etc. but you're finding out about it late because of the communication delay.
In those cases, you'll need to adjust your simulation based on this new information about what happened in the very recent past, re-playing your inputs with this new knowledge of the game state to arrive at a new outcome that's consistent with the "consensus reality" the server has authoritatively determined and broadcast to all players. You can then gradually interpolate the displayed state to this corrected state over a few frames to make the adjustment less jarring.
This same adjustment can help cover smaller divergence in your simulation outcomes due to (hopefully minor) non-determinism in your simulation - like variations in floating point rounding or physics resolutions.
How I think it should work:
My question is, why not just move the local player based on the movement, and send the new position to the SERVER every time it moves?
The biggest problem with this is if the server just trusts any old position it's sent, then it becomes easy for players to hack the game to move faster or teleport or clip through walls etc. Even if you try to add server-side validation, it's generally more work to verify that a given position is a valid outcome of the game rules than it is to just run those game rules on the input directly.
But since you say you don't care about cheating, you can ignore that reason (at your own peril, some would say, but hey, it's your choice to make 😉).
The other reason is that when a conflict arises, simulating from input helps us find the correct resolution to that conflict. If all the server has is a list of positions - some of them based on false assumptions about past game state as we saw above - then it has to work backwards to figure out how those game entities got into those positions, to then figure out where it needs to move them to instead. This again is more work than just playing the game state forward with the history of player inputs, and simulating forward helps you get a more consistent, predictable, fair outcome too. So that's why we often prefer this route, even when stopping cheaters is not a top priority.