I guess this depends on what you mean by "end up using some Erlang".
If you mean that you end up calling certain library functions and such which are written in Erlang from Elixir.... well, yes, and you need to by design.
But I'd argue calling a function written in Erlang or from Erlang's standard libraries isn't the same as having to write Erlang code. I use Erlang's ETS, its in-memory key-value store, quite a lot from Elixir. I'm calling the Erlang ETS functions, but I'm not writing Erlang code I'm writing Elixir code which simply calls the Erlang functions. To me that isn't the same.... which for me is probably good: I know enough about Erlang to read the docs and to read Erlang code well enough by now... but not to write it; I've been writing Elixir code for years now and never had to write actual Erlang to accomplish anything. The closest would be a matchspec (kind of a matching DSL used by certain built-in Erlang databases), but I don't consider that writing Erlang, but more DSL like. I've also used Mnesia from Elixir in the same fashion: I call the Erlang libraries which are Mnesia, but I'm not writing Erlang code to do it: I'm writing Elixir code which calls Erlang libraries.
I'd disagree with the larger statement where you say, "Elixir only has lists not arrays, so if you need a good indexed data structure you end up using some Erlang." You are correct that Elixir doesn't have arrays and only lists... but that's also true of Erlang. Elixir and Erlang basically share the same primitive data types. I have to assume by "a good indexed data structure" you are referring to the previously discussed ETS which is more a K/V store than something like a data or data structure. Otherwise, you'd have to be more specific to what you are referring.
I think it's true that if you are going to write any serious amount of Elixir, you will benefit greatly from having some familiarity of Erlang. Not because you're necessarily going to write Erlang, but because Elixir was designed to be very compatible with Erlang's approaches, philosophies, and, most importantly, Erlang's runtime the BEAM. Because we do use Erlang library calls we will read Erlang documentation, frequently. We will see examples of those libraries written in Erlang, errors coming from the Erlang side, etc. None of this is to say I have to "write Erlang" to do any of this, but familiarity with Erlang doesn't hurt at all.
In the end, Elixir is simply a more expressive way to address certain kinds of problems while still reaping the benefits of Erlang and its VM, the BEAM. If you don't leave the kinds of problems to which Elixir is well suited, you will certainly encounter Erlang's standard libraries and benefit from being able to read Erlang and its documentation... but you won't really have to write it, just call its libraries.