Threads are fascinating and multithreading will only become more valuable as multicore cpus become more prevalent. However, experimenting with them could very likely lead one into writing a game that is unlike, in some fashion, the thousands of clones currently being generated by game engine programmers, and we can't have that, can we??
I'd put the question in two stages. The first is whether the cost of managing either spawning or pooling is justified to begin with. That is where most of the answers seem to be landing in the negative for "traditional" game applications. Perhaps they haven't considered this: "No More Callbacks: 10,000 Actors, 10,000 Threads, 10,000 Spaceships" http://blog.paralleluniverse.co/
The second stage probably can be related to general tradeoffs about spawning or pooling in general. Spawning has more overhead per unit spawned (creation, garbage collection). Pooling has an up-front overhead greater than spawning (building the pool), but once the pool is created, managing the objects can potentially be less overhead since creation and garbage collection are avoided.
So, it is kind of like a classic breakeven analysis with "fixed" and "variable" costs. Spawning has more variable cost, pooling has more fixed cost.
A lot will depend on your intended use. How long will the thread run? How many threads at once? How much reuse are you looking at? Brian Goetz ("Java Concurrency in Action") points out that frequent, light-weight use of threads creates significant costs in building and tearing down the threads. If that is your scenario, then pooling is indicated.
If the threads will get a lot of use once made, and will be built infrequently, maybe spawning is better.
I don't know if there is a way to determine this except by trying and experimenting and profiling.
However, Brian Goetz does give this equation for tuning the size of a thread pool (in "Java Concurrency in Practice", 8.2):
N = number of cpus
U = target cpu utilization, 0 <= U <= 1
W = wait time
C = compute time
The optimal pool size for keeping the processors at the desired utilization is:
Threads = N * U * (1 + W/C)
The point is that one thread per cpu makes a certain sense, but if the threads spend a lot of time in a blocked state, it might make sense to use more threads than there are cpus. But Goetz also points out there may be other constraints affecting the best number of threads in a pool, such as external resource availabilities.
I hope all this adds something to the discussion, even if it isn't a clear rule-of-thumb answer.