Agreed!
The amount slashed for safety faults is fully programmable and not limited to 32 ETH. For example, one could delegate preconfs to a dedicated preconfer (e.g. a relay) which can pledge an arbitrarily-large amount of collateral, including non-ETH collateral. Another strategy to boost collateral may be for an operator to combine the stake from k validators to get k * 32 ETH of collateral.
Nope, that’s a misunderstanding 
A user can get a promise (within ~100ms, by communicating with the next preconfer) on the execution of their transaction (down to the post-state root, if desired—see the section titled “parallelisation”).
Agreed—I removed the sentence “This is roughly an order of magnitude faster than running an external consensus, e.g. as done by Espresso.”
Based sequencing with preconfirmations remains a tokenless, hatch-free, credibly neutral, decentralised, shared sequencer which reuses L1 sequencing and inherits its censorship resistance.
I think the point you are making is that when preconfirmers don’t preconfirm (e.g. are offline) transactions execution is delayed. If X% of proposers are preconfirmers then transaction execution can be delayed by 1/X% on average. The good news (as discussed on our call, as well as in the response to @kartik1507 is that rational proposers are incentivised to become preconfirmers so I expect X% to be relatively close to 100%. There may also be an opportunity to somehow enshrine preconfirmations and mandate that every proposer be a preconfirmer.
I expect the vast majority of transactions will be preconfed and that non-preconfed user transactions will be a thing of the past. There’s no execution latency overhead to preconfirmation (preconfed transactions can be immediately executed onchain by any proposer ahead of the next preconfer) and the section titled “replay protection” explains how to protect preconfed transactions from frontrunning.
Now let’s assume that for some reason a significant portion of transactions are not preconfirmed. Then any transaction that is frontrunnable (e.g. a swap) can be protected by encryption similarly to encrypted mempools. That is, frontrunnable transactions would go onchain encrypted and would only decrypt and execute after the preconfirmed transactions. Again, such protection is unnecessary if preconfirmations are used in the first place.
In your scenario the preconfirmer has monopoly power to execute transactions (and extract certain types of MEV like CEX-DEX arbitrage) for 5 slots. It’s as if their slot duration was a whole 1 minute instead of the usual 12 seconds. Longer effective slot durations definitely favour preconfirmers but are largely orthogonal to builder centralisation. (As a side note, building is already extremely centralised.)
This monopoly power to execute transactions is an incentive for proposers to opt in to becoming preconfers. You can think of it as a bootstrapping mechanism which temporarily rewards early preconfirmers and incentivises most proposers to become preconfers.
If the transaction is only valid if executed as preconfirmed, and the preconfirmed execution does not sandwich, then the transaction cannot be replayed to sandwich the user.
You can!
One of the value propositions of based sequencing is neutrality and tokenlessness. The based sequencer is a credibly neutral sequencer for L2s and their competitors to enjoy the network effects of shared sequencing. Moreover, using a non-ETH token will almost certainly reduce economic security. (Today Ethereum has $60B of economic security).
EigenLayer is not required—any restaking infrastructure (e.g. home-grown, or an EigenLayer fork with governance removed) could work.