I mean this in regards to the "true" message-passing type of actor objects, and not OO as it came to be post-C++ and Java. The reason being is that actors 1) fundamentally involve themselves with state and time, and 2) connect subject and recipient together directly.
In relation to 1), most business problems involve _data_ processing, and the thing about data is it is immutable. It's essentially a solid state type of activity, and bears no resemblance to the organic, messy world of biology where things are changing. For problems like these, you really want to avoid state in your program, and persist state after data transformation in an actual database. Concepts like stateful actor supervision hierarchies, and what to do with clearing mailbox state when something goes wrong are fundamentally complex. Those concepts are also broadly unnecessary (and arguably harmful) for most request/response or async pub-sub type software. I can't count the amount of time I've wasted redoing systems on an actor model to be a simple "stateless" request model. On all of those occasions, the model that didn't persist state in-app was more reliable, easier to understand, less code, and more maintainable.
With respect to 2), actors basically violate all concepts of dependency injection. Actors need to know exactly where they're going (or you can add a proxy, and now your state graph is even more complicated), and even with message passing, program flow is dependent upon _time_ and the order in which a program is run. This is a large step backwards in my opinion.
I feel that languages like Elixir that pride themselves on stateless, immutable functions, have a deep contradiction internally embracing the actor model, because it is none of those things. Sadly, I also predict that this generation of Elixir programmers will learn the lessons of the Waldo paper the hard way: you can't just throw an actor model over the network and have it work great. (I think it's especially interesting that most of the success stories around modern day actor systems involve problems that can withstand data loss: telephones, IOT, content, media streaming, games, etc.)