Since you clarified in the comments that you really want to know about TCP, the answer is simple: At this level of performance, it usually does not really matter.
If you aim for a higher level of performance, you'll want to use a different approach with far fewer threads than the ones you suggested.
Use 1 thread per NIC, handling every single client connected to that NIC. Because of the large number of clients you only do parsing, followed by the minimal preprocessing of the messages necessary to enqueue messages on the appropriate target thread. If you use UDP, this thread will likely also implement heartbeat and some retransmission request functionality as necessary.
Use multiple threads based on the game's design. Easy targets to split off into independent threads are chat and dungeon instances (if they aren't already on different servers), most everything else depends on the specifics of the game, although inventory is often a candidate for getting its own thread.
The primary benefit of a pre-processing thread for all incoming messages (per NIC) is scaling. Additionally, by moving the parsing and sorting to a different thread this is something you no longer need to worry about.
The downside of a pre-processing thread for all incoming messages is complexity if compared to the single threaded mega-application.
Using multiple threads for the initial processing of incoming messages is undesirable. First, it offers no benefit: A single thread is fast enough to parse everything the NIC and the OS can deliver, unless the parsing function is poorly designed (solution: optimize the parsing function). Second, it does introduce unnecessary race conditions: If 2 players want to pick up the same item, player A's packet may arrive at the server first, but player B's request may end up being processed first. Third, using multiple threads to parse and sort incoming messages ends up requiring more performance, primarily due to light synchronization overhead.
Using a thread per player is undesirable, because it leads to large synchronization overhead.