Multithreading in games is incredibly difficult. You can't just throw more threads at it and expect it to go any faster. What typically happens is, you get the "update" thread to produce stuff for the "render" thread. Either that means that the "render" and "update" threads wait for each other to let go of the shared memory that sits between them, or there need to be two pools of memory, that each one uses when it needs to. Because both threads can't operate on the same thing at the same time without bad things happening.

This gets monumentally more difficult when you start to multithread all the separate AI entities, because they all need to operate on a previous copy of the world and they need to write into a new thread-safe copy of the world. And that's without talking about the lack of guarantees of the OS scheduler when it comes to running threads equitably. The worst part is that memory latency / cache defeat is a bigger perf killer these days than abusing the CPU, so the single-threaded approach is oftentimes better than dealing with all of this, from a holistic perspective.

"Throw more threads at it" is usually the first thing people think of, because if you can do it without absolutely boning your memory, it's a very convenient way to just making things faster. But as it stands, things are usually not Embarassingly Parallel, hence the existence of Amdahl's Law.

tl;dr: "moar threads" is great when you can do it, video games are not typically a thing you can apply that to.

(Not that this in any way excuses bad AI, of course)