Let's say Alice and Bob have an active eltoo channel. They have transacted 10 times, so there's a history of 10 update txs (as well as 10 accompanying settlement txs, each spending their respective update tx's output).
We're at block 100, and for some reason they're not happy with their channel. Alice tries to close fairly, by publishing update_tx_10. But Bob tries to cheat by publishing update_tx_02 which had an associated settlement_tx_02 that distributes more funds to him.
Cheating scenarios
Scenario A: update_tx_10 gets confirmed in block 101, making settlement_tx_02 invalid (its input has already been spent by update_tx_10). After update_tx_10's confirmation, Alice and Bob have to wait for n blocks (a value they negotiated) before settlement_tx_10 can be confirmed, which distributes the funds fairly and in accordance with the final channel balance. Let's say that in this example n = 10. The delay is implemented with a relative timelock in the settlement path of update_tx_10's output.
Scenario B: update_tx_02 gets confirmed in block 101. Bob thinks "YES I'm gonna steal some of Alice's money!". However, settlement_tx_02 can only spend update_tx_02's output after 10 blocks so he has to wait.
Scenario B-1: Alice publishes a new version of update_tx_10, which now binds to update_tx_02 (instead of to the original funding tx). Since Alice knows she is under attack, she includes a decent (slightly overpaid) fee in this new version of update_tx_10. Bob wanted to wait for the timelock on update_tx_02's output to expire, but he's out of luck. Miners will not ignore the nice fee that Alice included in update_tx_10 and will simply try to mine it in block 102.
Scenario B-1.a: Bob takes the loss. He wasn't able to cheat Alice and he accepts that update_tx_10 and subsequently settlement_tx_10 will be confirmed shortly. The cost of his cheating attempt is the tx fee he paid on update_tx_02.
Scenario B-1.b: Bob is furious and wants revenge. He publishes update_tx_03 which, similarly to update_tx_10, binds to update_tx_02, but with a much higher fee, in the hope of beating Alice to the punch and getting update_tx_03 confirmed in block 102.
Scenario B-2: Alice's node crashes and she did not set up any watchtower services for her channel. 5 hours later she got the node working again, but it's too late. The relative timelock on update_tx_02 expired, and Bob has gotten settlement_tx_02 confirmed as well.
Bob can stall the settlement of an eltoo channel, but there is a cost associated to this. Also, Alice has a say in setting the cost, since by increasing the fee on her (final) update transaction, Bob has to follow and increase the fee on his intermediate update transactions to have a chance of winning the confirmation race.
What about the HTLCs?
In all of this, there is no 'problem' for HTLC outputs. A key characteristic of lightning payments is that in case of dispute, you simply put the tx containing the HTLCs on-chain. So, if there are still HTLCs in Alice and Bob's settlement tx, these can simply be resolved on-chain, by spending the HTLC outputs along their redemption or refund paths.
