There just aren't many modern multiplayer games where slow players can negatively impact the experience of others, and that's because the industry has learned how terrible the experience is.
And that's for players playing in good faith on bad connections - abuse by inducing latency was a big thing in the past. Think a player that runs out the clock when they're a move away from being checkmated.
Basically the only time you'd ever want to operate the system to pause if a player fell behind is during a tournament, where fairness is more important than player experience and they know that going in. And even that, IMO, is questionable.
Consider for instance the situation where-in one player's simulation enters the spiral-of-death, under the policy that you're proposing this player is effectively removed from the game; I would say this is a substantially worse trade-off -- I know that I would personally prefer some mild annoyance of brief pausing as opposed to a player leaving the game (and in session-based games, as RTS's generally are, a team-mate leaving often ruins the entire game)
Abuse is indeed a problem that most games I've seen of this nature don't address, and while there's no perfect solution, it can be quite effectively curtailed. In the systems I've designed, the basic principle is that each participating player has an allocated amount of wait time which serves as a quota that is charged while-ever the game can progress/run, but cannot, due to them being in a wait-state (connecting/loading/reconnecting/stalling/explicit pausing/whatever). There's some extra logic for handling the oscillation of wait-state.
While a client is catching up, you run the sim in a loop and don't render the game.
The deterministic simulation code is only a small part of the overall game logic, and you can run it much faster than real time.
If a client is slow enough to genuinely experience a spiral of death, the game will not be playable for them, and "mild annoyance of brief pausing" is not remotely what the other players will experience if they're forced to stay in sync.
Wait time is the common solution in older games to prevent abuse, yes. But it doesn't prevent somebody with high ping making a game run at half speed.
Go play Company of Heroes 2 with a packet loss simulator. Even as the bad client, it's totally playable. For everyone else, it's silky smooth.
I don't think you'll come back and tell me you prefer the implementation in AoE II Definitive Edition.
In the end this is still a decision regarding how to handle player's falling behind; too far and they're effectively taken out of the game as they're no longer interacting within a sufficient approximation of the current state.
Under what design is "high ping" going to cause the game to run at lower "speed"? The only possibility I can see is where-in the turn period is, for some bizarre reason, also the granularity of the simulation step and you're also adapting the turn based on player latency (in aid of fairness, usually)
Having implemented such a system myself, a few times now, it has in practice performed sufficiently well.
DE is garbage in general so it's not really a fair comparison.
If you could simply wait a few seconds for them to catch up, they'd also be able to catch up without a global pause.
In any case, we're going in circles. I came to this thread to claim that "If one person lags, everyone lags." is not intrinsic to this kind of net code, and you disagreed. Company of Heroes and my own games are existence proof of my claim. I'm not really interested in arguing about it any more - millions of players can't be wrong.