To add to this statement: Input latency is a much broader issue than collision latency - a large scale of collision latency is produced simply by being an online game, regardless of how you're trying to represent the events. So the collision being subject to a tickrate is hardly a dealbreaker. Variable timesteps can be a little bit better at performance or responsiveness, but it comes at the expense of flooding additional concerns about consistency throughout the main loop. The modern fixed timestep treats a tick rate as delta times being partitioned into quantities of ticks, but also passes the time each tick represents into each update as a way to ensure that timers and time-centric physics can exhibit perceptually similar behaviors if the tickrate, and thus the duration of each tick, changes.
Input latency, OTOH, is something that has challenged developers from the earliest days since it has to do with how fast you propagate new input through the main loop to the output device, and the timestep's interaction with input is not straightforward. Arcade games could drastically improve their feel just by capturing and debouncing input multiple times a frame, even with the simple screen-refresh timesteps that were the common practice.
Input latency, OTOH, is something that has challenged developers from the earliest days since it has to do with how fast you propagate new input through the main loop to the output device, and the timestep's interaction with input is not straightforward. Arcade games could drastically improve their feel just by capturing and debouncing input multiple times a frame, even with the simple screen-refresh timesteps that were the common practice.