(this got out of hand...) I understand what you're saying and think you're right, in terms of not having had the same time running in the wild to have the same knowledge base and ecosystem as other solutions.
But looking at what it actually is, it's a layer over the much older underlying technology, which is Erlang, once you look at the frameworks used, they are basically implementations of things we consider old approaches, despite including new features. Some examples:
- Phoenix - it's a MVC framework, it's not much different from any MVC framework except it doesn't have the "model". You can entirely use it in that "boring" CRUD app way and it will be a great choice. It's performant and has a templating system for HTML, a plug system that looks like middlewares. But if you need to use web sockets without ceremony or want to try something shiny like live views, you can as well. You're not forced to though and you don't need to use nodejs for your js either (as an example)
- Ecto - It looks like an ORM but isn't an ORM, it's default choice for database is Postgresql. It's a library that mimics SQL itself (the helpers and the way you use it are as they would be used in SQL but designed to be chain able and sanitised), it also has easy ways of executing SQL while still sanitising it and also of writing raw SQL. So, pretty boring in all senses except the slight change in syntax to write the queries in elixir. This means for instance a distinct clause would be
distinct(query, [table_mentioned_in_query], asc: table_mentioned_in_query.platform)
This is not written as sql, but it maps to sql one to one. It uses schemas which are just that, schemas that map how values are dumped and cast from the DB, they're not models/objects, they're just data structures. But if you want to get fancy it also has embedded schemas if you want to use jsonb for instance, that allow you to use jsonb columns while still maintaining a "typed" schema from dump to read.
What may look a bit alien is perhaps the access to OTP libraries that Erlang offers, the way the VM works and certain abilities that come from the way you will structure an app, but even those when we think about them, it's basically what any OS does, or the way kernels work. You have processes, they have identifiers, you can name them, you can run a lot of them concurrently, they can have separate lifecycle trees/dependencies, they have interfaces, you pass "messages" between them. Maybe what's "new" when you compare it to other languages is that this is not usually available to them but I would argue that most of our systems are implemented exactly in that way because it's the most reasonable outside very specific constraints/needs.
When you use Elixir, Phoenix and Ecto you don't need to use these (or understand them deeply), usually the libraries take care of that for you. You can start as if you were writing a nodejs, rails, .net, python or whatever application. But then if you actually need you have a host of utilities and a runtime that I think is excellent for the kind of things most apps out there need, in a single runtime, and you can take it pretty far before you need to extend the stack and that has value in itself I think.