What I would say is that my mobile apps have very large buttons. Any 'miss' could only really occur at the edge of each button.
So in that case I could use the event coordinates in contrast to the dimensions of the button to decide whether to revert to onClick() behaviour.
Edges ==> onClick()
Center/Sweetspot ==> onTouchStart()The problem you are mentioning has also been solved by Google. In Ice Cream Sandwich when you click on a link that is close together with others, it will magnify the area to make it very clear which link you want to click. This is a solution to your mis-clicks - not a latency delay on every click so that you can fix it if you clicked wrong...
Don't confirmation dialogue boxes and password confirmation fields fall into the same category? They assume imperfect user input, and their mechanisms for avoiding errors slow the user down.
I think there are specific cases where eliminating the delay is appropriate. The very real concern is that developers will use this with abandon. There are many sites where it's easy to mistap, and the delay behavior serves its purpose well. Developers should think twice before breaking whole-platform conventions. Whatever they might personally think is "the right way," breaking with conventions almost always surprises and frustrates users.
The delay is there to allow you lift your finger and see the link turned gray (or whatever the selection color is). This feedback is crucial even in cases where you tapped on the right thing--how else would you know you got the right thing?
There are valid reasons to override this, but developers and designers should be sure that their tap targets are huge when they do. Otherwise they're depriving users of a pretty important piece of feedback.
On HN, for example, I'll frequently hit the article link instead of the comments and this delay (combined with the network latency) often lets me re-tap the right link.