I'm not sure there is much in the way of formal research into this area. You could perhaps posit some numbers based on an understanding of human reaction times (which has had extensive academic study), although note that this and what you are talking about are not the same thing. The acceptable delay between making a motion with a mouse and seeing a result is almost certainly much smaller than the time it would take a human to react to something displayed on the screen with the mouse.
This is, in fact, an important consideration. While in some cases it may be acceptable to only process new input around 30 frames-per-second, as with rendering (the idea being that that's the persistence of vision interval anyway), you could in some implementations of this approach have too much round-trip delay between an action happening on the screen and the player's reactionary input getting back into the game logic.
In the real world, usability tests and general playtesting usually catches this kind of thing (especially for games that also have a networking component and can have the additional network round-trip delay). Based on feedback from playtesters about how "laggy" or "floaty" your controls feel, you will adjust your input timing or optimize the round-trips to achieve better results.
Consequently I think it's a bad idea (premature optimization, in a way, as Byte56 commented) to focus on achieving a theoretical ideal input delay on the misguided attempt that you will "reduce computer power." You almost certainly won't, first of all, and you'll be solving the problem with the wrong constraints and flexibility areas in mind.