Average user doesn't choose an expiration and the reality is we can't have too much lag in our interfaces specially the social media side. My argument was that we should increase the RC costs before it gets too late and adds too much delay. If RC costs become too high then we can consider increasing the block size. This won't add any delay.
IMHO the downside of added delay is more than the weak accounts not being able to transact for a period of time. The added delay affects every single user equally regardless of their HP and I think that is a bad design.
I think RC in fact should create friction but not too much and not too little.
transaction_status_api requires you to have the transaction id saved somewhere and that limits it to only the wallet broadcasting the said transaction. I think BTC wallets show the incoming transfers as well that are not included in a block yet. AFAIK they don't need to have the trx_id. I think the ideal system would let you see the pending transactions related to any account on their account history page.
During flood attack the network is in survival mode. Nukes are flying and we need to take shelter and survive long enough for the attackers to run out of ammo. We should certainly not be concerned about not being able to walk the dog in that time. As long as network does not break and there is as little fallout as possible, the attack should be considered a failure. But yes, during attack users need to adapt to be able to still transact if they absolutely need to.
Surcharge mechanism will be triggered as early as first block from the start of flood attack even on default setting (depends mainly on size of transactions), but it won't trigger in normal burst-of-activity situations. Even with the mechanism activating, it will take time for the attackers to be affected - their RC levels need to drop significantly before they start to be locked out, or the mempool needs to bloat to scale up the surcharge. In the latter case everyone weaker than the attackers will be locked out. Even when attackers start to be affected, the mechanism just lowers the intensity of the attack, so it is easier to survive.
It makes no sense to ever implement something like that in Hive. Outside of deliberate attacks, short lived burst-of-activity or network congestion all transactions are included in the nearest block and they even become final before you could refresh history page.
Looking at your concerns I came up with a harassment type of attack that could probably be performed by a single whale :o) It wouldn't affect the network safety, but could negatively impact user experience. Unfortunately to test it (and also potential countermeasure) I'd need to make a lot of changes to the tools I have and I'm busy with other things.