"but then fail to point out one?"

I didn't point out one, I pointed out thousands. All the combinations of message busses and serializations and schedulers and monitors you can imagine. Systemd monitoring a selection of processes that read and write from kafka queues in a cluster of VMs. Lambda functions that read and write Amazon SQS/SNS queues written in Go. Azure Functions using JSON to communicate over Azure Service Bus with Terraform configuring redundancy. A microservices architecture orchestrated with etcd based on gRPC services communicating with each other on a NATS message bus. Arbitrary mixes and matches of all of these things, probably the most common architecture of all at a corporate level.

Many of these beat BEAM on some metric or other that may be important at some point. For instance it's not hard to beat BEAM on performance (though it is also not hard to lose to it on performance; it's a very middle-of-the-road system on that front, which I mean completely literally). Another thing that you get very naturally is heterogeneity; if you want everything on a BEAM system you really have to stick to BEAM's languages, which is a pretty big issue in most cases.

The reason I say BEAM is not the gold standard is that there's still people running around who speak as if BEAM is the only way to write reliable software, that it is still the only way to have lots of independent services that communicate by passing messages, that if you don't implement every single one of gen_server's features and work exactly like OTP's supervision trees and if you don't handle errors by crashing processes, then you're not operating at Erlang's Golden Standard.

And that's not true anymore. There's plenty of alternatives, many better than BEAM on many fronts. BEAM is not the natural obvious leader standing above the rest of the crowd, secure in the knowledge that nothing is as good as it is and never will be. It's now down in the scrum, and as long as it is metaphorically running around claiming it's somehow unique I'm going to grumble about it. It's not even good for BEAM itself, which really ought to be pitching integration rather than "Look! We solve the reliability problem uniquely!"

To the extent that people are reading my post and basically backpedaling and insisting "Oh, no, it's the integration all along that we've been pitching"... well, I don't particularly enjoy the rewriting of history, but other than that... yes! Good! Do that! Pitch the integration! It's a legitimate advantage! But it's not 2005 anymore. Every major compiled language can handle tens or hundreds of thousands of connections on a reasonably sized server. Every language has solutions for running this robustly and with decoupled architecture. Every language has solutions to the problems now. BEAM's in a crowd now, whether it likes it or not.

There is no gold standard for these technologies any more. One might as well ask "well, what's the best computer?" There's no answer to that question. Narrow it down to "what's the best gaming computer" and you can still ask "what sort of games" and it'll be a crowded field. There's more options that anyone can even analyze anymore.