That's not quite it. The timeouts aren't there because there may be more data coming - the timeouts are there because for most things more complicated than the input case, you don't know whether or not userspace has consumed the event. That means that on Android you have little things like 5 second timeouts in the MMC code purely to handle the case that there's no easy way to detect whether userspace is done dealing with the SD card that you just inserted or not, or (as in your case) how long it'll take some magic packet you received via wifi to bubble all the way up to userspace. It's difficult to see these kernel-level timeouts being acceptable.
You can defer the timeouts to userspace instead, but then your userspace has to be amazingly aware of how everything ties together - rather than having generic userspace, you now need userspace that knows every single wakeup event that the kernel may generate, and whether or not it needs to take a timeout on them. That's more complicated than the existing Android case.
I'm not arguing that the wakeup events code is bad or evil or does nothing to get us closer to a model where Android works, just that right now it only solves the simple cases and doesn't have a clear strategy for solving the difficult ones.