This is very much true, setting up the attack initially described by @kladkogex is a logistical ordeal, but I think we always should assume that the worst scenario can happen and will happen if we let it.
Many factors at play here, but the attacker could act cleverly and corroborate on random, organic bloats of the main chain.
@kfichter was saying that, despite the latest gas price in the most recent block, there’s still absolutely no guarantee that the next block won’t contain a list of transactions with attached fees worth ㆔1 each if someone is willing to spend that amount of money. Presuming normal conditions though, indeed, the last block might be a good proxy for estimating the gas prices, but this thread has been presuming horror conditions, not trivial or rational ones.
Method 1 is indeed a UX nightmare and method 2 might be a scary model from an economic standpoint. If I know there’s always the threat of paying double or triple or more to get my funds back to Ethereum, I wouldn’t even deposit on Plasma in the first place.
Perhaps the optimal solution is to have a model where the operator is able to top up the bonds of every undercapitalised exit. He can afford to periodically scan the Plasma contract for any spooky exits and the main chain for sudden gas cost increases. The presumption here is that the operator has a strong incentive to keep the Plasma chain running, because the cost of a successful attack would be higher than the summed topped up bonds. Afterwards, they could impose slightly higher fees on Plasma to amortise these expenses. Now, there is an elastic limit of how much the bond top-ups can be, but there’s a relatively similar limit to the main chain’s attack size, hence I intuitively feel that these two vectors eventually cancel out.