Have you ever designed/programmed a multithreaded application? Some tasks just don't lend themselves well to multithreading. For instance, just looking at EU4, how would you divide the workload across threads? How would you synchronise the data access without creating bottlenecks where multiple worker threads are waiting on another. It's extremely complicated to do multithreading right, and even harder in a realtime game like EU4 where latency is critical. CIV is actually easier to multithread because it's turn based.
I imagine the biggest bottlenecks at the moment are AI and scripts/events.
Sure, but EU4 has lots of tasks that are nice and isolated / parallel-izable. In fact, your question is kind of an interesting intellectual exercise, so I'll take a shot at it, bearing in mind that I have zero knowledge of the internal implementation, and could easily be reinventing the existing design. (I also agree that this would be nearly impossible to retrofit onto an existing game.)
Starting from state management, I would have 3 versions of the game state: prior month (read only), live, and next month. I'd spin up AI and event threads for each individual country, synclock at month end, applying updates to the "next month" snapshot. I'd then apply a base + delta, diff-based algorithm to apply intra-month changes, which generally means changes of ownership and military position + strength. This monthly pulse would also be the strategic military AI (including unit building). The tactical AI would probably have to be realtime and global, but again would be diff-based so that it only recomputes in response to change events (position changed, unit built, battle started, pre-arrive, etc).
This design creates some real challenges (i.e. overall AI military objectives only changing once a month), but it seems like a workable approach from the outside. It also makes bugs come up more easily (because of a missed / forgotten trigger or side-effect in the diff-based code). However, it allows a relatively static state environment for the worker threads to run against. It would probably influence future design freedom as well, since there would be an incentive to push things into the monthly tick and make fewer dynamic changes to game state at arbitrary times. Thus, advisors and monarchs might always die at month start, or nations might always compute liberty desire based on the trailing month so that it didn't have to be updated live.
Of course, I wouldn't be surprised if someone who has spent more time thinking about this (i.e. Wiz, for one) could easily poke a dozen holes in the design, and has implemented an even more thorough or elegant design. Still, it's fun to think about, at least until they decide to give us all access to the internal design documents.
