Do you even deem it a good idea to do hefty things like collision checking in the networking thread and to delay the networking thread to a rate?

There may be good reasons to use a networking thread, but doing simulation in that thread doesn't seem good.
And, usually, you would just use non-blocking networking rather than a separate thread (unless you have to use Java or somesuch.)
That is, polling/draining all incoming packets should take a very short time in a tight loop, and then you could spend the rest of the CPU stepping physics.
When the server doesn't spend CPU on animation/rendering, that should generally not be a big performance problem compared to clients.

THAT being said, if you serve thousands of users in a single process, then a whole thread for networking might make sense; the decode and dispatch/enqueue of packets to the appropriate game entities may use a noticeable percentage of a core, as would the interest management (who can see what?)
Then the problem becomes that physics is inherently N-squared -- if all players lay themselves in a pile in the town square, they all need to collide against each other, and you get lots of interacting pairs. Even fast ball/ball tests end up being expensive when you have to do two million of them per frame (2,000 users, all tested against each other.)