This is debatable and I'd say absolutely not :)
What would you choose?
It'd be great to see that change over time, but to be honest I'd be more excited to see some movement behind the crystal lang, because I love coding in Ruby. All of my side projects are now being written in Ruby because I don't need something that scales in microseconds, or 10's of milliseconds for that matter, and I feel so much more productive.
Again, I hope I'm proven wrong. I think Phoenix has a lot of potential, but it still has a long way to dethrone Rails.
Do you realize how biased you sound to be?
I've been using Rails for 10+ years now and setting up a phoenix app is very intuitive. A lot of "oh this is like X in Rails". IME most of the complexity was around JavaScript and that's changed with esbuild.
However it sets up with very similar patterns to Rails. Something I'd expect as it's creators came from Rails. Usually the differences are specific to FP vs OO.
Admittedly coming in from another language especially with an OO background would be harder as it's a smaller community than Rails and doesn't have 10 years of documentation sitting out there. That said documenting elixir code is much easier IMO, so that is sure to change. Also the scope of FP languages requires significantly less documentation IME.
The only thing vs Rails that I have found somewhat needing more attention in Phoenix is SSO integration but it's there and progressing especially with the Phoenix 1.6 changes.
It is not. From the outside the end result for the user might be similar, but that's where the similarities end. Elixir's LiveView what I assume you're talking about keeps state on the server, in memory, and sychronizes changes back to the client over a websocket. Hotwire is "stateless" in the sense that no end user state is kept in memory on the server across requests. You can also use most of Hotwire without websockets.
My previous company was using Elixir, and they moved away from it because everything took longer to develop, the ecosystem of libraries was very lacking, the tooling (such as editor support) was terrible, and it was very difficult to hire experienced developers.
Performance wise, I agree, it is faster and you will use less servers. A nice problem to have to be honest.
But I insist, they have almost nothing in common other than maybe the end user result. The approaches they take are architecturally very different and with very different trade offs.