There’s the same sort of realtime system in the BEAM. When you run nice to have and mission critical software together life is much less exciting if you have something handling such things.
luckily, mobile devices never encounter problems like a backhoe cutting it off from the network.
For example Elixir/Erlang are currently used in certain IoT applications.
Lights, fridges, washing machines.
People say this, but it's not that helpful, IMHO. Front end and backend have different concerns, usually different teams, and using anything other than the preferred language for a client platform tends towards clunky UX.
You can do some sort of core networking library that's shared between clients, and I guess there's reasons you might want that to be Erlang, but integration feels like a lot of work when you can just deal with it in another language. Client side concurrency is so much less than server side concurrency, it'll be fine.
Is this a reason to use a different language? Or sometimes an effect if doing so?
You can't actually build a mobile app entirely in JavaScript, but if your used React Native the parts that actually deal with materially interfacing between the client and the server aren't in JavaScript. At best you can share some typescript definitions.
Java on the server is extremely different from Java on client, and the same can be said for Swift. What do you get to share? Maybe the code that serializes and deserializes messages? But even then that's thanks to a library, not the language (and if you're using a feature of the stdlib, it's almost certainly just as easy to use in any other reasonable language).
Pyodide and PyScrpt exist and you could certainly build a full stack web app with them. Why doesn't anyone, then? It's because doing so doesn't solve any serious problems or make anything much better.
For a large company with lots of developers? Makes less sense. Better use the best tools for the tasks.
Web apps are JavaScript. Android apps run on a JVM. iOS apps are whatever can compile to native code and use Apple's APIs. When you avoid the runtime of the language that you're expected to build for on a platform, you'll inevitably spent most of your time working just to get a handful of features that you need from the runtime into the language you're choosing to use.