I watched the PDC Ander's presentation again partially and there's couple answers to questions made using the Q&A feature that make similar point as was made above.
1. Because await can be "buried" so it's not clear what will happen in the method.
(2. Because of restrictions similar to iterators (no unsafe/ref/out) - easier to notice this restriction)
However as I suggested in the op, since most code using VS, alternatively to adding a method modifier based cue, the IDE could highlight in some manner that there are surprising things going to happen in the method. I looked at the further arguments for "async" posted in this thread and most if not all of those issues are about highlighting one fact or another / preventing confusion so they don't really present a strong argument against using IDE instead of a modifier for that purpose.
So to reiterate, the issue I have is about having to do more work that a modern IDE like 2010 has capability to do for you. With operators like await/yield and with other similar things, a case is made for having visual cue besides the command that there's something "funky" going on so really this is just a language designer answer to an IDE problem. (atleast for now, I'll read Eric's post when it's out)
And what if someone's using a different IDE, or not using an IDE at all? Tying basic language readability to the IDE is a bad idea.