The exaggerated response time example was for a typical usecase. The amount of situations where there is actually 60fps rendering going on and necessary are few and far between. Most browser usage is of fairly static content. Especially in the case of a mouse click, when you expect something to change on the screen and almost everything in that change will depend on something much slower than the simple IPC call (if that even happens) of tranferring the mouse click event. Splitting things up between multiple processes can slow things down if done badly, and can also bring tremendous speedups if done right. I assume the folks at Mozilla know what they're doing.

And yes, I'm ignoring memory usage for now. Mostly because it is a horribly complex thing, especially in multi-process situations. The numbers are notoriously difficult to interpret between working set, commit charge, shared memory, memory mapped file IO. Unless you're actually debugging the code or an expert, it's basically just guesswork. Mozilla have improved Firefox's general memory footprint significantly these past few years and they're not going to throw those advancements away easily. Again, I trust them to know what they're doing.

As I said before, I'll reserve judgement on e10s until I get to experience it in daily use. All I will say in advance is that the premise and the stated goals make a lot of sense to me and it seems like a highly desirable technology.