i will try to explain the argument even though i don't agree with it anymore
rollups are the only type of sidechain that *can* be trust minimized in the event of a soft fork. they are not trust minimized in their current state. trust minimized means that users have a cryptographic guarantee that they can leave the system whenever they want (unilateral exit). Liquid, RSK, etc., can never provide this. you will always trust sidechain operators (miners, stakers, functionaries, etc.,) to be honest.
rollups, in their current state, are arguably more centralized and less trust minimized than all bitcoin semi-legit sidechains, so none of this really matters. still, i'll elaborate
the reason that rollups can be more trust minimized sidechains is that rollups are subsets of bitcoin - they rely on bitcoin for ordering and data availability
when updating the state, rollup full nodes are the parties that effectively decide whether the state is "valid" - i.e. the sequencer cannot post an invalid state root // diff to bitcoin and advance rollup state. if it posts a blob of "incorrect" data the system will halt. rollup nodes always check bitcoin to determine if state is updated. sequencer just provides preconsensus. sequencer and prover can't steal (ideally)
so the sequencer posts data to bitcoin, full nodes (who are also bitcoin full nodes) check the state by looking at rollup tx's in bitcoin, state good, move on. if not everything stops
so while people think the sequencer is the one who ultimately decides the ordering, it's not really the case. bitcoin provides ultimate ordering and makes said data available to rollup full nodes to validate // advance their state.
because of this model, a "prover" cannot create an invalid validity proof to checkpoint the bridge and steal all the money. it too could yeet some fake data, but the bridge would be unable to validate it. in this perfect world, a "zk rollup" would have the bridge be secured by cryptography and cryptography alone.
but, there's a catch! bitcoin cannot verify a validity proof within a single bitcoin block (script size too large). we need new opcodes to do this (i.e. GSR). this means that we do not have a system where the bridge is secured by cryptography alone. because of this, citrea's bridge relies on a bitvm implementation via a federated set of operators for a number of roles & functions.
tl;dr citrea's bridge has three spend paths:
1. 10-of-10 multisig (federation)
2. 3-of-5 security council (smaller federation)
3. bitvm pre-signed operator fronted tx's that can be challenged if invalid by one of the 10, federated operators
ultimately, the core security model is that 10 people can steal your money or 3 can. as you can see, this is not a system secured by cryptography alone (which is what a "zk rollup" really is)
there are other benefits for users if bitcoin is used as a DA layer (i.e., users can bypass the sidechain operator and force their transaction into a sidechain block), but it really comes down to the bridge. the reason to build a rollup, in the context of bitcoin, is because rollups can have really good bridges in theory if soft fork. if the bridge isn't better than liquid, than i agree, the entire premise is a bit weird because it's more costly at the end of the day for rollup users and not very scalable because bitcoin has very low throughput
if bitcoin had a soft fork and could do real "zk rollups" (zk is just a marketing term fwiw, the correct term is "validity rollup" and even i think that is a marketing term), then any user could start a rollup full node, from genesis, by querying data from bitcoin. they could run their own prover and generate a validity proof of current rollup state to prove to some bridge that they can spend their funds out of it. this is amazing in theory, but in practice *very* hard to build
sorry for the novel. as i've presented, there's an argument that rollups are great systems if you think bitcoin is getting a soft fork, but in current state, i don't see how rollups are more secure than sidechains from the lens of a "bitcoin asset" user unless their bitvm implementations are: 1) sufficiently large and 2) w/o security councils. even then, im not sure how great the improvement is