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.