Isn't this just lockstep networking?
Yes, though using a server as a relay.
You say there is no master game state, but there is a server.
Correct - the server does not have a copy of the game state or execute any game logic. It only batches and forwards commands sent to it.
What's the advantage of this over having a master game state?
It's simpler to implement. If there is a master game state, the protocol must be able to communicate arbitrary changes in state. With this protocol, only commands such as "move here" or "shoot this" need to be sent across the network. Also, there's no complicated predicting logic, and a whole bunch of cheating methods that involve tricking the master game state don't apply.
What about desynchronization caused by packet loss?
Unlike a lot of game networks, I'm using TCP rather than UDP. TCP takes care of detection and retransmission of lost packets.
What if you want to enforce hidden information?
Then you need to store state on the server, which means this approach doesn't work.
Isn't this kind of slow?
It is, compared to using a predictive approach. For an RTS, it doesn't matter. Slow here means a command latency of one round trip plus about 160 ms.
Why have a central server at all?
You could also have each client talk to each other client. However, the server performs as a simple and clear timing system: the update interval in which a command arrives at the server is the update interval for which the command counts.