Graphical IDE support tends to develop later in the technology adoption life cycle once the technology is more mainstream.
And that makes sense given that there is only so much effort to go around when there is only a relatively small community effort that can be expended on developing the ecosystem - i.e. there is an opportunity cost to developing graphical tools that only becomes worthwhile once a technology acquires a certain critical mass. Before that point is reached, effort is probably better spent on language, deployment and runtime improvements and command line (i.e. scriptable) tooling.
People preferring graphical tools are usually neither in the “innovators”, “early adopters” and possibly not even the “early majority” group - because technologies in those phases tend to be largely supported by command line or text-based tools.
And then there is the whole “Language vs. Tool mavens” thing: Oliver Steele: The IDE Divide (2004-11-21)
I suspect that Elixir is still early enough in it’s life cycle that there are more productive ways to expend community development effort than creating graphical development tools (though in OSS anybody can develop and provide what they want).
it’s difficult to keep the mental model of how everything is connected.
That’s simply a matter of familiarity.
Also there is no guarantee that any particular graphical representation (or interactive model) provided by any tool is in fact a good basis for a mental model - often multiple representations are required to cover all the useful views.
For example, with UML people often provided class hierarchy diagrams because they were easy to provide rather than providing activity and sequence diagrams which actually show how the system works.