Compounding slashing risk on a single stake
The same feature that makes restaking capital-efficient, letting one pool of stake back multiple services at once, is also its central risk. A validator that opts into several services now has its stake exposed to several independent sets of slashing conditions simultaneously, and those conditions are defined by different teams, with different code, different failure modes, and different maturity levels. A bug, a misconfiguration, or an unexpected edge case in any single one of those services can trigger a slashing event against a stake that was originally locked up purely to secure the base chain. The validator's downside risk isn't the sum of a few isolated, independent bets, it's a stack of exposures against one shared pool of capital, where the weakest link among all the opted-in services can cause a loss that has nothing to do with the validator's actual behavior on the base chain.
This matters because it changes the risk profile of staking itself. A capital holder who originally accepted the well-understood, well-audited slashing risk of the base chain may end up, through a validator's choices, effectively exposed to the security practices of several newer, less battle-tested services they never directly evaluated. Even a well-intentioned, competent validator operator can get slashed because of a flaw in someone else's service code, not their own mistake, which is a meaningfully different kind of risk than the base chain's slashing conditions were originally designed around.