An excellent essay. The current "median language" is certainly JavaScript, so using a language that can do things JS can't gives you the advantage pg is talking about.
What problem domains will Elixir add substantial power for? What use cases do you think it will be a game changer for? Would you consider the difference in the future between Elixir and JS in terms of productivity/power the difference in the 90s between Lisp/Python and Java/C?
With Elixir and the Phoenix Channels library[1], soft real time, bidirectional pub-sub communication is incredibly simple. Startlingly easy, in fact. If this describes "the tricky part" of an application, Elixir is a substantially better choice than other languages right now.
Comparing Elixir to JS isn't fair. Even ES6 is still kind of a shitty language with shitty concurrency primitives. The main reason JS enjoys the popularity it has on the server-side is because lots of people are afraid of learning a new language and everyone knows it from the browser, not because JS is a particularly expressive, fast, elegant, or concurrency-ready language.
That's basically meaningless in the presence of the internet. I'd say "low latency".
Just a bit of a funny comment/aside, but the actor-based message-passing concurrency of Erlang/OTP and Elixir is actually pretty similar to the classic object-oriented programming of Smalltalk, etc.
"I might think, though I'm not quite sure if I believe this or not, but Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it's based on message passing, that you have isolation between objects and have polymorphism."
Which, yes, is another way of saying "blame C++ then Java".
In general, assuming programmers aren't smart enough to learn a different syntax has always been a winning bet in programming language design.
It's highly productive, especially at scale, relatively bug-free and easy to test (being a pure functional language with immutable data), designed for (and makes almost trivially easy) extreme concurrency without blocking (even by GC), minimizes the risk of crashes due to errors (YMMV of course), nudges the programmer in the direction of sound and productive architectural decisions, is fast "enough" for most non-number crunching uses (much faster than the 90s dynamic languages, slower than Java/C#/Go/Swift), and, although the ecosystem is still small, it makes up for it with probably the best standard library there is in the form of OTP.
I'd say its problem domain lies in the area of large (large codebase and/or large userbase) realtime apps. Or, more generally, it offers its best productivity relative to the competition for applications where most computations are not particularly complex and/or are repeated, but they may need to be performed at a very high throughput. An excellent server/networking language.