several companies accepting Monero insisted on 15 confs during the attack. it depends on the specifics of the attack I'm sure, but it seems like 6 conf on Bitcoin is excessive. in the case of this specific attack, the transactions that were reorged out reverted to the mempool and settled later. but the attacker *could try to double spend by spending, reorging and then broadcasting a conflicting transaction in hopes that it gets mined before the first. monero doesn't have RBF. but timing a transaction in hopes that your pool is going to get lucky with a reorg, and then get lucky again with a rebroadcast transaction seems like a pretty poor bet. and exactly what is this transaction for and how is the double spend not detected immediately...? does not seem particularly useful. I think these kinds of attacks are mostly useful simply if you want to destroy confidence in the chain. so in this particular case, I would say the attack was a failure.