It’s important to have definition of “trust” for this statement.
If we use an Etheruem optimistic rollup with on-chain data availability guarantees as an example and we assume it’s out of beta, we have three situations where I can be in trouble:
1. Censoring my transactions
2. Refusal to allow me to withdraw my funds to L1
3. The network itself shuts down and there are no longer any operators
If I am censored, I can force transaction inclusion by directly submitting the layer2 transaction to the inbox on Ethereum (the validator will get punished if they don’t include it). This will be more expensive for me since I have to interact with Ethereum, but it should only be done very rarely and my next rep should be to exit the L2 network.
If the network refuses my withdraw transaction, I can perform an emergency exit by making a call to be L1 contract and demanding an exit happens (I can also use the strategy in the censoring case).
If the network shuts down, then my only choice is to perform an emergency exit, which has probably already been started by other participants on the network.
These options do get more complicated when you start using layer 2s with off-chain data availability committees (validiums and volitions) and that’s where you do need to trust third parties to ensure you can get the correct transaction data, but it only requires that one honest party is serving that transaction data.
The trust requirements are actually pretty low for “out of beta” L2 networks while keeping the costs low enough that people can afford to use them.
ZKRollups have similar features and even lower costs but ZK-proofs are still very new and harder to reason about.