Thus far, these have been my top considerations when determining Threads vs Processes :
Threads will use up much less resident memory than Processes. Yes, with dynamically linked libraries a lot of memory is shared between the Apache Control Process and it's child Processes, however each new Process will need to instantiate all of the modules you have enabled.
This is easily testable by comparing the memory usage of each Process where you have, for example, either 5 Processes and 1 Thread each or 5 Processes and 25 Threads each. In my case here, each child Process takes about 7 MBs regardless of the amount of Threads.
It takes longer to initiate in terms of time and cpu cycles to load a new Process than it does a Thread. This can be tested by verifying avg amount of pages served via 'ab'.
A Processes Threads all depend on the Process .. The biggest concern here, is that if something happens to the Process it will affect all the Threads that are associated with it. If you're running with a single Process with a bunch of Threads, then when the Process dies so will the Threads. More Processes would therefore cause a better separation, and thus greater "fault" tolerance if you will.
Related to (3), for modules such as PHP, their memory is loaded by the Process and shared across all of the Threads. This means that if you have php with memory_limit set to 100Mbs with 25 Threads below, then at max load technically each Thread would be able to allocate a maximum of 4MBs each ( course it won't happen this way, some will hog, some will starve ).
So in the end, it really depends on your use case .. That being said, you'll want to maximize the amount of Threads used so as to diminish memory usage and increase responsiveness. However, you'll have to balance that with a proper amount of Processes for better fault tolerance.
Course I'm no expert here as I've only recently have had to become concerned with this, so I look forward to see what other answers might pop up here !