First of all: How many actors? If it's 50, anything you do will work.
That being said, a thread per actor is the worst possible idea. I hope I don't even need to explain why.

Second of all: What physics engine will you be using?
Most physics engines want to do the physics thing for themselves, so your update needs to synchronize with that.
E g, you'll have to ask all actors what to do with the world state or input they have, then step physics, then tell all actors to update their post-physics reactions.

Third of all: Why do you think "reference to world" is a big thing to send? It should be a single pointer.
If you're trying to use Enterprise programming libraries and object serialization within your game engine, you are doomed to fail.
Those systems are built to serve very different use cases than game engines.

Can you use reactive programming in games? Yes! But beware libraries that try to make bindings fancy, or that prefer allocating new objects to re-configuring existing objects in place.
Can you use threading in games? Yes! But you'd want a work queue, and N worker threads (one per CPU,) and each actor/step/whatever is a work item. You'd also want cheap synchronization on this queue (a la lock-less FIFO) if you have lots of actors.

Btw, everyone "touching" the world was one of the poor design decisions that Project Darkstar (Sun's ill fated MMO engine) did.
They ended up locking way too much. And the scalability ended up being negative -- the more servers they added, the fewer entities the system could siulate overall.

A game engine architecture that scales better, at least across CPUs, is one where state is double-buffered. The "current state" (state of the last tick) is available for all actors to view; actors compute the new state into a "new state" area. So there are two sets of state; an actor is not allowed to read "new state." Once all actors have updated and you commit the step, swap the state areas, and "new state" becomes "current state."
You can also scale this across networks, where actors would send a replica of their new state to other listeners.

The other problem you'll run into is that simulation is inherently an n-squared problem, because all actors could want to congregate in a crowded area -- dogpile; auction house; indoors firefight; whatever. When all actors can affect all other actors, that's a N-squared problem that can't be reduced. Only game design can help alleviate this problem.

Marshelling (inter)actions (at a sufficient time granularity) and then combining and arbitrating them together is preferable to a immediate tick activation of all involved objects (where you may also have to refigurer what other object are involved EVERY TIME).

Depending on you simulation, you might have a cascade of sideeffects (which just cause more activations ad nauseum).