In order to answer that question, I think we need to recap how Elixir/Erlang handles concurrency and synchronization: Isolated processes that communicate via messages, and general immutability of data.
If we leave ETS out of the equation for now, that means that nothing is shared between the processes.

When one uses multi-thread programming as a concurrency paradigm, the rules are different: Memory is shared, and one must ensure that this does not lead to trouble using semaphores or lock-free algorithms.

The disadvantage of Erlang’s approach is that someone has made a choice for you. You cannot easily share data between processes and you cannot easily implement your own lock-free algorithms.
So there are situations where it is not possible to achieve the same performance in Erlang as you can using multiple threads.

That being said. I think that in most cases the process-based model with messages being the way to exchange data between them, is vastly superior to threads.
The model has also been copied to many different languages and environments. Probably because it is much easier to work with, and because the drawbacks are few.

I’m a big fan of cons included when there’s a bunch of pros. However, I was racking my brain a bit to think of practical cons with the approach in Elixir.

For me, efficiency is not necessarily a practical con because I wouldn’t say I was ever hindered by the parallelism of Elixir. But I can appreciate the approach it takes having an overhead and people considering that a con.

To me, maybe the biggest con is that parallel and synchronous code are something that can trip people up. It’s not this magical system that prevents coding or understanding errors. A person may think some code is parallel but then it converges into a synchronous choke point because they missed something.

Obviously the con is when you absolutely positively need synchronization / barriers / semaphores / mutexes like in a normal DB engine.

Another con could be that the preemptive scheduling nature of the BEAM loses some CPU cycles to achieve the godlike responsiveness of the runtime. People working with lower-level languages, especially Rust lately, are efficiency fanatics and disagree with that tradeoff. (Although some that I have worked with admitted that the Erlang’s idea of processes with isolated mailboxes would kill 90% of the bugs they encountered in their code.)