While certainly UE4 is under heavy FPS influence from their previous titles, I don’t think at all that it’s a bad thing to begin with.
I do like Epic to make things like StartFire( I assume this will be deprecated later down the road) to trigger serverside respawn to be a more generic functions, but many of the multiplayer side of thing is really important for your to keep eyes on if you are aiming to do, if at all, a multiplayer RTS.
They needed time to clean up some of those heavily FPS influenced parts, some of those you mentioned, to be more abstracted. ie instead of using say, bIsSpectating || bIsWaiting && !IsFrozen(), to check for if a player can respawn(restart), it should be a function call that lets people can easily override it and just return true or false.
Despite RTS(control multiple pawns and defeat ends a game) and FPS(control only single pawn and can respawn) have many things different, but on multiplayer engine side it’s not that much different, sending controller message to tell a pawn to shoot, and sending message to tell one of your RTS unit pawn to move, is essentially the same thing on architecture side.
What Epic really need to do is, make a thorough documentation and diagrams to explain the architecture more clearly, so people can have confidence to dive into one part of it and find what they want to change.
Even if it’s relatively well commented code, going through the code is no small task for people like me that have no previous unreal engine experience.
(I made my diagram like only half way and are already bouncing around 10-ish cpp files in Runtime\Engine just trying to understand how a player from connect to join and spawn for the first time works.)