It definitely is a different concurrency paradigm, but it is not ‘new’. It is known as the Actor Model. I emphasize concurrency paradigm, because it can be combined with different other programming paradigms. While functional programming combines with the Actor Model very nicely because of its focus of referential transparency and no-shared-state, other implementations like the OOP-Actor Model language Pony exist as well.
Saying that the actor model is about consensus alrogithms is a bit like saying that concurrency is about locks: Not true! Those are there to do the opposite: sequentialize (in the case of locks) or collabotrate (in the case of consensus) as part of the bigger system. But using these types of techniques should obviously be done sparsely rather than everywhere, because then you completely subvert the features of your system.
Also: ‘Concensus mechanisms’ (You seem to be speaking about distributed consensus here, looking at your links to Raft) are only interesting when we have multiple peers that might be separated by an untrusted and unreliable network! Inside the virtual machine of a single Elixir system (or even when setting up multiple Elixir nodes and connecting them using Distributed Erlang), using these kinds of mechanisms does not make any sense, since parties can immediately communicate, the network is trusted and transparent, and all peers can be trusted as well since they are all operated by you.
There are much easier ways to share state between processes: The easiest way is to send a copy of your own state to a different process. Also, Elixir processes allow you to perform not only asynchronious calls, but also, if you need to, perform synchronious calls, making sure that two processes are (for the duration of that sync call) both in a known state, which makes it a lot easier to reason about the system.