Inputs would then be time sensitive, right?

They don't have to be, but they should be. You've got roughly the right idea on how to handle it. The server and client need to roughly agree on what a particular tick means (e.g., tick X after start of multiplayer session, or something). Latency (RTT) measurement/adjustment is still going to be necessary to get good results.

My next question is in regards to what gets sent out to all clients (state updates or commands).

State updates, generally. Commands can be rejected or modified based on server simulation state, and you want to send the results of the command rather than the command itself. e.g., there's no reason to send the FireWeapon command to all clients if the server rejects the original, or the server might instead send an OutOfAmmo event to all clients so they know to play a "click-click-click" sound or the like.

Client sends movement command (like move east from this position) -> Server accepts command and applies to simulation
Server is on a loop that sends delta updates to all clients (raw positions and interpolate on client)

Close, but not deltas. Just send the actual values. Deltas imply that you can't tolerate lost updates.

You can mostly get by with three broad categories of messages:

- Unreliable, ordered. Updates to properties that change very frequently and so you can just constantly emit the most up-to-date value over the wire. If an update gets lost, there's no need to retransmit, because a new value will be sent anyway. Ordering matters because you don't stale delayed packets to override data from more recent packets. ex: position data for moving objects.
- Semi-reliable, ordered. Updates to properties that change infrequently but you only need to know about the most recent value. If an update gets lost, you must retransmit, but instead of retransmitting the lost update you can send the current value, because you don't need intermediate values. In other words, the message itself is reliable, but the server is free to update the message with new values, rather than having to add new messages. Ordering matters because stale packets should not override more recent packets. ex: hit points, active inventory item, position data for stationary objects (inc. previously-moving objects).
- Reliable, unordered. Fire-and-forget events that a client needs to know about. Losing the event would result in a broken or unsatisfactory play experience, but the order of application does not matter. ex: triggers for sfx or vfx such as s weapon being fired, chat messages.

I posit that you never strictly need reliable ordered messages (e.g., TCP) for real-time gameplay (though it's probably a far better choice outside of the real-time parts of the game, e.g. for browsing DLC or the like). Also note that you never need truly unreliable messages: if you don't care if it ever arrives, don't send it in the first place.

This question comes up every two weeks! In fact, the three main networking models mainly separate themselves by how they deal with this case.

There's a thread just a few ticks down that talks about this in some detail.