Starcraft is an RTS rather than an MMO as you described. Furthermore, it has a very limited number of players. To keep the input and visuals synched it does use similar techniques, but not quite the same as an mmo. What you described is pretty accurate. I am a game developer, though I haven't worked on an MMO. I have studied the technology. I am an Independent Game Developer (indie intentionally) and I also have a full time job as a Senior Network Engineer.

Typically whichever system is chosen to be the server (even in a P2P) mode will be the one that is considered authoritative. It is the one with the authority to dictate what actually happens. It is the one which will either send updates to the clients, or is the one that will validate input from clients such as in a Peer to Peer environment.

The validation is important. As you increase the responsibilities/abilities of the client/peer on the communication side beyond simple input you also open windows for cheating/exploitation. You'll see this more on First Person Shooters where the input has to be VERY fast and network latency can be a problem. This then opens the doors for things like aim bots, and other things. Some people can get skilled enough that the anti-cheating that is supposed to detect bots can false flag people. I've seen this happen. It is much like the problems with trying to detect bots vs. people on steemit.

In Real Time Strategy games the input of the client is sent to the server (or authoritative peer) who validates it and relays it to the other clients/peers. This is a chance to prevent invalid input. In some cases it may even send it back to the client/peer it received it from and some game developers may make a game only respond to clicks that have been verified by the server/authoritative peer. Really there is no SILVER BULLET of "this is how all game developers do it" These days the cost to enter the game development arena is at an unprecedented low. It is almost as available as a pencil and paper. This means a lot of people are jumping in with "I have a game idea" and have not learned how to actually do that. Some of them are marketing their idea (sometimes with great success) without actual experience in delivering what they are promising. This means the market is being flooded with some pretty poor quality projects, and it still has a lot of good ones too (more than ever) it just requires the consumers be a little more aware than they have in the past. There are a lot of ways to make a game.

The MMO space does tend to be very specific though. Network latency tolerant designs supporting a lot of people usually means input processing needs to be a little less frequent per player. So it does interpolate/simulate/predict on the client the motion and results of input. Occasionally the server will synchronize to update the clients. When there is a problem either due to the game or network lag you'll see the results of this in the form of what people sometimes call "rubber banding"... where a player was one place and then suddenly is in another as they receive an update from the server saying "you should be here". This is primarily required due to the quantity of players.

This is why MMOs are largely target, and then click a power bar that cools down, etc. This is a good gateway for limiting how fast a player fires off actual important input. Rotating your camera, zooming, and all of that stuff the server doesn't particularly need to be aware of. So it is your movement and the UI commands you click on that it cares about. This simplifies the size of the network transmissions a lot and let's the clients handle the rest.

Anyway... I don't think I've done much more than ramble here. I think what you said combined with what Dan said are pretty accurate. Though nothing in game development is set into stone these days. :) (perhaps never was)