"could be" is all very well, but for the people using bitcoin right now, it needs to be "is".
How long do the delays have to be? Does it matter if the recipient isn't using a randomisation service? Etc? I'm not saying these questions are unanswerable, it's just that they need real solid thinking done on them, which (as far as I know, which isn't very far) hasn't really been done. And then the answers need implementing.
Annie Lowrey discusses Bitcoin in Slate. No clear thesis, but important that it gets attention there. She gives a general overview, with emphasis on its benefits to fringe elements on society, and gives quick attack at the end. The attack seems misinformed, but it links to something more interesting, specifically...
A technical critique by Victor Grishchenko, PhD, who was mentioned here in the context of causal trees. He describes a few problems he sees with Bitcoin:
1) Asymmetry favors attackers, in that it takes a lot more effort to check for double spending than to attempt a double-spend, eventually requiring "supernodes" that have disproportionate influence over the network.
2) It needs to continuously spend spend cycles to stay free from attackers. He then describes an attack I don't quite understand that involves holding on to a discovered block and then broadcasting it at just the right time
3) It doesn't compare well against existing systems in terms of privacy, speed, or transaction cost. (I found this questionable because the system he's comparing it to is still subject to warrants, and Bitcoin takes significantly less time -- 1 hour or so -- to ensure a transaction than the wiring transfers Grishchenko discribes.)
Finally, he credits Bitcoin in being advantageous similarly to Bittorrent: the latter was clumsy and complicated compared to regular downloading, but could perform well enough in a niche niche to force change in the broader markets.