I think there’s two ways in which this isn’t true – if your deterministic algorithm is “highest feerate txs”, then by including some very high feerate txs you could be able to mine them into your block immediately just by following the deterministic algorithm. But in addition you could also allow for 5% of the block space to be free-use (similar to the old space for mining txs by priority) after having filled up 95% of the block space deterministically.
Maintaining a deterministic mempool at pool-consensus level is likely fairly complicated in practice; particularly in rolling out upgrades/changes to relay policy (eg TRUC relay, different RBF policies, new soft fork features, changes to min fee rates or limits).
It’s also likely a bit more complex if you have to be able to efficiently calculate the top of the mempool from a previous state, for dealing with beads when the braid has width greater than 1.
At ~1/1000th the difficulty of a block, with a pool at 10% hashrate, you’re receiving a new bead every 6 seconds, so probably don’t want to receive 2MB of new tx data every bead. Probably it would work to take sha256(sharehash) as a random seed and then allow 10% of beads to include 150kvB of tx data that will be incorporated into descendants, while the remaining 90% of beads can only include 5kvB of tx data – that’s about ~2MvB tx data relayed over 100 beads (which is 600s for 10% hashrate at 1/100th difficulty).