In your scenario the action started at exactly the same time. Then things diverge. The game state changing and reacting is driven by the game refresh rate (which may be independent of the video refresh rate). The latency between the game state change and the visual feedback is directly linked to the video refresh rate.
As an example if you have the same game running on two machines, one at 60Hz and the other at 1Hz. In both cases you press the button at exactly the same time. The game update will process that button press and start a muzzle flash, that took some period of time that we will assume is equal for both machines (i.e. I won't make the slow rendering machine also have a slow game update, even if typicaly the two are tightly coupled). So 1/nth of a second after the button press both machines are ready to show the muzzle flash. On the first machine you will see the muzzle flash 16.6 milliseconds later. On the 1Hz machine the muzzle flash will appear 1 second later.
Now, my example is a bit extreme (to make it obvious that there is a difference. Do not think that this is irrelevant in real word cases. I worked on one of the first fps games to win awards for jump puzzles that were not atrocious. Early on we spent a lot of time testing the game at 30Hz and at 60Hz. If we ran the game at 30 we could effectively double the quality of the graphics, which the art team obviously wanted so that they could do even greater stuff. But after blind testing we found that everyone noticed "something" was better about the game that ran at 60Hz. Reducing the latency between the button press and the jump allowed players to gage the jump point more accurately. Reducing the latency of the joystick movements allowed the player to guide their landings more accurately.
One final note, maintaining a consistent frame rate is even more critical, players have to know that when the press "x" they will get the same result.