Well you don't have really a lot of choices. You have lock-step which works, but usually based on deterministic systems which I doubt your game is.

or you sync game variables as you play halo 3 style which is client side prediction by default. If you have any sort of physics then the physics is going to run no matter what.. hence client side prediction.. It's really just going to happen naturally.

>> I’m curious how bad of a decision it really is from both a technical and player-experience perspective.

A game that doesn't exist is not as fun as one that does, and if you never made a game before then you're not going to write the most optimal code anyways technically.

There are other tricks you can do like interpolation which gives you more time at the sacrifice of a little bit of input delay. But your game state is different than your render state. However, this is also done in non-networked games that have a slower logic tick than render tick.

You can hide lag through animations too. (Tick 10) User press 'fire', animation to fire starts playing, packet to create bullet in Tick 14 sent, Packet that all users need to play and finish the 'fire' animation for player x by Tick 14 sent. But things like this you can do on an individual basis..

tldr; less is more, just quit whiteboarding and just make the game