So, again: why? I still don’t understand the motivation for this.
I am asking because you are very unlikely to find anything that is
For your use case, the constraints you set up for this problem may just be a distraction, but YMMV.
No. I don’t want to be that strict. 
Since nobody has mentioned it yet, Plots.jl is a good option.
OK, but, for example Gadfly is purportedly 100% Julia, but if you dig into the source, it uses Compose.jl, which again somewhere ccalls out to some libpango/libcairo etc. (I don’t know anything about these.)
But somewhere, graphics libraries will call some C-code, I guess. Where is the line?
I heard that Julia generates machine code and then what actually runs is machine code, not Julia code at all. Does anyone know if there’s a language that avoids this?
Yes, but I didn’t know this when I asked the question.
If I were to write a book called Doing Math with Julia, I would be a little disappointed, and so might be many of my readers, if the book taught them Matplotlib instead of Gadfly.jl. Many might ask themselves, “Why don’t I just read Doing Math with Python and use Python to plot my data?” On the other hand, if the book used Gadfly.jl, the question might not even occur to them.
I’d settle for minimal non-Julia libraries. In theory, it should be possible to replace these with Julia implementations, too, though many might not consider it practical.
Maybe you can use Gadfly.jl.
Good idea.
At some level some library will call out to some code that isn’t Julia. It’s just a question of how deeply buried you need it to be. With PyPlot, Python is probably too close to the surface for you, is that correct? Even though all your code will be in Julia? While Gadfly calling out to Compose calling a C-library for drawing primitives is ok?
I would think that Gadfly.jl or Makie.jl should be ok. Plots.jl are considered native Julia, but check out the various backends to see how early they call out to other languages.
But please note, that by your standards, matplotlib probably isn’t native Python, so “Doing math with python”, should rather be “Doing math with python and c++”.
Just out of curiosity: Does Julia have any functions to draw primitives on the screen?
I think perhaps there is a communication disconnect on what you are after. If your goal is:
If you are otherwise indifferent to how things might be implemented, and are looking at this from a user perspective rather than a sense of programming language purity, then keep in mind that the recent Julia package manager features are amazing and whatever binary backends are required will be seamless to them.
I think the best starting point packages for new users are
These are the safe choices. But there are different opinions on all of those
Both, if possible. Doesn’t the second point also imply the first?
I was also hoping to avoid any binaries that were compiled using some other programming language including C or C++, but this desire was secondary and apparently unrealistic and shouldn’t even be a concern.
Yes, and the Matplotlib website should read, " Matplotlib: Visualization with Python and C++".
I don’t know about those hypothetical readers, but personally, if the book is about an actual subject matter that is not plotting (eg “math”), I would consider plotting pretty accidental as long as it works and I can get the examples to run.
You may find it similarly “impure” that a lot of linear algebra uses LAPACK, which is again not written in Julia. This is actually more relevant in practice than plotting (eg for generic number types), nevertheless it is practical and you can forget about it 99% of the time.
Not at all. Just don’t use pyplot.
The aversion to things in the background compiled in other languages should be relaxed. At some point there is always some library behind things… The very legitimate concern of cross platform binary issues is largely eliminated in the last few versions of Julia’s package manager
Wouldn’t this also imply a relaxation of the aversion to the two-language problem? Yes, the background library is largely invisible to the user, but if I can peek under the covers, wouldn’t it be better to discourage a two-language (or three-language) solution by not using it where possible?
BTW: Makie.jl calls into OpenGL code (C, C++).
The two language problem is not that people are able to use software written in two (or more) different languages, it’s that people are forced to write code in two (or more) different languages in order to do what they need to do. The problem with Python/Matlab/R is not that they call BLAS/LAPACK (and other libraries) which are written in C and Fortran, but that in order to build solutions to many problems, one is forced to resort to implementing part of the solution in C or C++ in order to get sufficiently good performance. In Julia, you’re able to call existing code written in other languages—it’s one of the strengths of the ecosystem—but you’re never forced to write your code in anything other than Julia.