I think you missed the point. It's not about just spawning threads, but to actually use them for performance gains. Interestingly, all the things you mentioned could or should be accelerated on a GPU, not on a bunch of CPU cores.
The key to multithreaded scaling is dividing a workload into independent work chunks and let the cores chew at them, this is very difficult for games, as they are a pipeline of serial tasks, where only some smaller bits can be parallelized, but all of them needs to be synced up many times throughout the pipeline. For a game with a tick rate of e.g. 120 Hz, there is an 8.33ms window for the entire game simulation, usually starting with input event processing followed by game logic like collisions etc. If the game uses particle simulations etc. for effects, this has to come after the core game simulation, but before the rendering. The overhead of synchronizing threads grows with thread count, so there will be a point where you get into diminishing returns and not to mention stutter.
And when it comes to the rendering, there is really no point in throwing more threads at it, as the CPU only needs to keep the GPU busy. While it is possible to have multiple CPU threads build a single queue, there is no point to it as it will only create more latency on the driver side, not to mention synchronization problems. The only real purpose with multiple threads for rendering is to do different tasks, like having one thread to load resources while another is rendering. There will be very few real-world cases where more than 2-3 threads would be useful for the GPU in gaming.
