David Pollak wrote a very detailed description of Scala SDK Actors on the Lift discussion list, some serious flaws are pointed out as a justification of why Lift has it's own Actor library:

• Lift creates/destroys an Actor for each Comet request. This rapid creation/destruction of Actors caused memory back-ups, and the existing Actor code seems to be oriented to long running Actors rather than Actors with Object-length lifespans.
• The FJ libraries used for Actor scheduling have problems on multi-core machines and are also a source of memory retention issues.
• Replacing the FJ libraries with a scheduler based on java.util.concurrent exposes race/deadlock conditions related to the fact that some parts of the Actor processing (e.g., testing mailbox items against partial functions while the Actor itself is synchronized)
• The Actors require external threads to function and it's not possible to create external threads in the Google App Engine (making Actor-based functionality including CometActors non-functioning in GAE apps)
• Actors are fragile when exceptions are thrown
• Actors have running and not running states (as compared with objects which can always respond to message sends). In practice, managing the running and not running states is as hard as managing memory in C.
• There are hidden actors associated with each thread which display the above fragility and state management issues
• And as a practical matter, I've got a couple of applications that are going into production over the next few weeks and cannot wait for the various fixes to make it into Scala 2.8 and the hacks and work-arounds that I've done to the 2.7.4 Actor libraries became too complex for my comfort.

Interesting to notice the authors worries about overcoming some limitations to run Lift on Google App Engine, what would certainly boost it's main adoption in a near future :)