But, due to latency, the server will always be ahead of the clients, right? So when the server receives an input with tick count 15 (from client A), it might actually be at _simulationTickCount 30. What does it do in that case? Furthermore, another client, B, which has more lag than client A sends his tick count 15 at 30 server tick rate... What should the server do?
For this type of game, yes: the server lives in the future relative to the clients, or the clients live in the past from the server.
The server needs to operate basically on a sliding window. When something comes in, the server needs to validate it both with normal validation rules for bounds checking and such, and to make sure it makes sense at that point in time. If it makes sense that a player was at a location and fired at a recent time, it can insert the event back into the simulation and work forward from there. If the time is too far in the past or there are other problems, the event could be discarded or replied to with a failure of some type. If validation shows other oddities like the player being in the future, logging and triggered responses can also be appropriate.
It certainly adds complexity to projects, but done well and coupled with local animations and audio it makes the gameplay experience that much nicer for competitive games. Especially in systems where projectiles take actual real time to fly through the sky and the simulator accounts for that, it can provide even more realistic experiences.