Phoenix works within existing Elixir constructs like macros and modules, so it keeps a lot of the nice interfaces of Rails without the magic, how things work is pretty straightforward.
It is worth stating that the way Erlang/Elixir manage processes is completely different than most other languages and that has to be grokked at some point. Thankfully the framework abstracts a lot of that.
The Elixir and Phoenix docs are also pretty good. They're not Django-level (what is), but they're good.
Phoenix 1.3.0 really helps you understand that you are just making an Elixir app with some additional features. I don't think there is as much "magic" as Rails.
There's almost no magic in Phoenix, it's modular from the start and is really just a collection of libraries held together by some mix tasks to help you structure stuff.
Phoenix is much more straightforward and explicit but macros are used a lot in both Phoenix and the Elixir standard library. I think most of the macros are fine but opinions vary widely on that.
I tend to think of "magic" as meaning fragile, indirect coupling; for example "magic numbers" at the start of files, which are only meaningful if the consuming application has a corresponding pattern in its database.
Or sets of things which only work if given in a particular order. Or unrelated functionalities which interfere with each other due to implementation details. And so on.
In other words, leaky abstractions where thinking in terms of the concept has so many edge cases that it's easier to think in terms of the implementation instead. Or conventions which can only be used via memorisation, trial and error, stack overflow and reading the source (often this is due to shoehorning things into language models which aren't amenable; e.g. all of the things aspect oriented programming tries to do)
