What you seem to miss is that C++ also has some inherent value that cannot be replicated in Erlang. Namely: C++ is not assembly. You are already working on a higher level language. So the question is not "assembly or some higher level" but "how high a level should I go"?
Your response is essentially: "you should go to the highest level you can for concurrency, which (in your opinion) is Erlang".
The problem with that: you essentially reduce the whole problem domain to handling concurrency. Not what I call a good engineering analysis.
How about reusing HUGE EXISTING C++ libraries for his problem domain, instead of replicating them in Erlang?
How about reusing a ready team of C++ experts in his company, instead of retraining them in Erlang?
How about reusing existing tooling and infrastructure his company has for C++, instead of throwing it and using Erlang?
How about interfacing with external systems for which he has C++ drivers, but no Erlang ones?
You say: "The fact that something is possible is less interesting than how simple and well-supported it is". Maybe. But well supported is also not just a language attribute. How well supported it is within the industry, within his company, with his toolset, with the code he has etc?