This is not really a defect but an enhancement.

My suggestion is to check in which thread the method invocation is currently running for methods annotated with @UiThread (without delay). If the current thread is already the UI thread, there should be no handler.post of a Runnable but instead the method should be executed synchronously.
I encountered undesired side effects when being already in the UI thread an calling such a method because of the delay in the execution.

In the generated code it would roughly look like this:

if (delay == 0 && Looper.getMainLooper().getThread() == Thread.currentThread()) {
  // On UI thread.
  // execute method directly
} else {
  // Not on UI thread.
  // create runnable and do handler.post
}

http://stackoverflow.com/questions/2848575/how-to-detect-ui-thread-on-android

At the moment I don't have the time to look into it for myself, but if others are interested in this feature too but nobody wants to do it, I could try it for myself in the next weeks.