Agree that the code examples look like communicating sequential processes (CSP) and/or async/await-style concurrency (i.e. co-routines in C++). To me this is not "Actors" at all. Actors don't "wait", they receive and send messages, and optionally specify the behavior for handling the next message.
What are actors doing between finishing processing the last message and receiving the next one?
yield to the event loop
So they're waiting.
not really, they yield to other event sources, which is the opposite of waiting (which blocks forward progress and is a violation of real-time guarantees)
The actor itself can be said to be waiting. When it yields, the thread is then able to run another actor which was waiting on a message, and which then has a message on the queue.
I think these things can be equivalent. It all depends on the definition of wait.
The simple example can be x86 with monitor/mwait instructions. These will suspend a hardware thread until it can be awoken when the memory write happens to the monitored address. Nothing happens on that cpu thread in the meanwhile. Yet at the same time if things are being virtualized the higher authority exists and it can do something else with the CPU until the write. Same for OS type of event synchronization like Linux futex.
I would argue that the wait abstraction is more powerful. The alternative isn’t powerful enough to enable these kinds of “wake me when I can be useful again” behaviors.