Oh, there certainly can be 10k or more user events per second. Even ignoring the extreme case of network cards (10GbE cards can generate so many packets that you have only a clock tick or so to process each byte), mice can easily generate a few thousand events per second, and eye trackers will probably be even worse. I don't really want my CPU pegged because I waved my mouse around the screen -- not unless it's really got work to do, that is. Processing the mouse events is not work. (Note that if you're running X on a uniprocessor system this probably involves lots of context switches between multiple distinct processes, but even that is many many times faster than process creation.)
The softer version of fork() you refer to is called thread creation. It is faster -- I can generate a few tens of thousands of threads a second on this system -- but still not anywhere near as fast as context switching. You are still throwing performance away for, as far as I can tell, no benefit.
Worse yet -- if you're receiving a stream of events from some input device, they are almost certainly related in some way, and you almost always want to process them in the same process, or at least in related processes. Kicking off a new process for each event seems likely to lead to cursing from developers as they have to marshal the things back together again before they can process them. End result: a slower system, annoyed developers, more complex and buggy code, and... uh... no benefit, as far as I can see. What benefit is all this supposed to bring? Is it just 'more processes -> more isolation -> always necessarily better'? 'cos I used to think like that, and it just isn't so.