You don't need interactions between entities at every point in time. There are very specific sync points during a frame and there isn't many of them (maybe 5 or 6). Your units can also be organized in a table where each row can be updated in parallel before moving on to the next.
Many types of software can get away using only concurrency or parallelism. Game engines have to master both. You want parallelism to crunch your unit updates and you want concurrency to overlap your render pass on top of the next frame's update pass.
Now it takes a change in perspective on how to structure code and data to properly exploit multiple cores to their full potential. It is certainly possible to have interaction in the game world and do it in a multi-core multi-threaded way, it just needs smarter structures and better organisation of data.
Game developers have and will adapt to this.
Games are still just an update and render pass in a loop. Nothing will change that, they might be decoupled and overlapped but they're still present. They're just much more complex than they used to be. Some engines will fork/join at every step (sometimes hundreds of times per frame), others will build task graphs and reduce them and a 3rd team will use fibers to build implicit graphs. No matter what you do you're still executing code with very clean sequential dependencies.
Game engines started going multi-core at least a decade ago. First by using one thread per system, then moving towards tasks. Today I don't know of any AAA game engine not already parallelizing its render path and unit updates massively.
That's a common trope; it mostly applies to the rendering path. AI / Physic engines are nicely scalable with the number of cores (AI in particular, because a) it's oftern agent based, which naturally work concurrently and b) with AI, slighly relaxed synchronization constraints sometimes generate some desirable degrees of fuzziness and unpredictability ... although this is probably a very slippery slope ...)
I don't know if that's strictly true, but I do feel games aren't as easy to split across threads/cores as many other types of software. Ultimately, a game boils down to one big giant blob of highly mutable and intertwined state (the world) that is modified very frequently with very low latency and where all reads should show a consistent view.
In other domains, avoiding interaction between different parts of your application state is a good thing that leads to easier maintenance and often better behavior. In a game, the whole point is having a rich world where entities in it interact with each other in interesting ways.