The middleground I'm pitching is that that you run the simulation on the server and client, but give the client authority over moving and shooting.

The client simulates its local player movement at 60fps so there's no movement input lag, and it broadcasts the player position (coords, angle) to the server 20 times per second or something. This spares you from the hard topic of interpolating input desyncs and and client-side optimism.

The server updates client positions in its own simulation as they come in, and broadcasts snapshots to the clients. The clients just update enemy positions as the server broadcasts them. They'll be a bit choppy, but this spares you from the hard topic of interpolating old data.

The server simulation can be the authority of other things, like whether or not a player runs over a powerup, whether a bomb hits a player, the score, etc.

Pros:

• Your networking code can stay naive and simple while you focus on building the game.
• No movement input lag, so it's playable compared to other naive solutions (like making the player wait for input roundtrip).
• Spares you a lot of work when the reality is that your game will never get big enough to have a problem with cheaters.
• Can add server-side validation as needed.
• Starting with a simulation on the server and client on day 1 makes things easier down the road.

Cons:

• Server-side validation is less general than 100% server authority + lag compensation. If you get big enough to have cheaters, server-side validation becomes an arms race.
• Probably gonna be a large refactor to migrate authority away from the client.
• Still have to roll your own synchronization illusions for non-player-movement stuff, like bullet projectiles.

If I was smart enough to get lag compensation working on day 1, I'd do it. But I wasted many weekends trying to get it working, and I ultimately realized that it was a procrastination -- that I need to be working on the game.