I think the old paradigm of inputs triggering animations doesn't work with gestures. You need something different. If you look closely at what games do, outside of using a button to fire, there actually is a delay between the button press and the execution. Mario doesn't do a 180 instantaneously, the Prince isn't in the air the moment you hit the button, and Samus doesn't instantly turn into a morph ball. But this is exacerbated with gestures, because it takes longer to input a gesture than a button press, so now you're not just delayed by the animation, but by the time it takes to input.
I think the connection between input and animation needs to be reworked with Wii games. I have some ideas about how things could be improved, although I don't have the means to implement them. For example, doing a throwing motion and then watching a throwing animation to throw a grenade just doesn't work. It feels awkward, and it's hard to learn. What you could do instead is tie the playback speed of the canned throwing animation to the velocity of the controller is moving (you could even make it really simple by tying the speed to the velocity component of only 1 axis), and have speed_grenade = speed_final. That would minimize delay a great deal and improve the recognition of the input, since now you're not trying to do any gesture recognition. Further, I think it would make the action more learnable, since the player will see and feel near-instantaneous feedback to his actions. And since the feedback is constrained to a predefined animation, you'd get rid of that feeling of frustration players have when their gestures aren't recognized. The animation would just be moving forward (possibly backward), either more quickly or more slowly.
Maybe this specific example would need a good bit of work, but I think this sort of thinking, which is basically what Wii Golf does, will work better than gesture recognition.