I think you might be fighting an uphill battle here.

Some developers prefer Python, some prefer Ruby. An individual developer might be able to reel off a list of reasons why one is better than the other, but in the end it comes down to something intangible and subjective - "Ruby just feels better" or "Python fits my brain better".

The concept of "magic" is very similar. What feels magical and opaque to one developer might be plain and obvious to another. When you ask what "magic" means, you'll get different answers from different people.

From my point of view (as a Python/Django developer), even the basic commands that Rails uses feel strange. Compare the very first line of code that you run in a Django project vs a Rails project:

    django-admin.py startproject mysite

with

    rails new blog  

The former says: "run the Python script called django-admin.py" (which immediately tells me that this is just a Python script that I could read, if I were so inclined) and pass the arguments "startproject" (which is a clear description of what is about to happen) and "mysite" (which is, fairly obviously, the name of the project to start). This reads like a sentence of the form 'use <tool> to perform <action> with arguments <arguments>'.

The latter says: "run the command rails" (what is this? A Ruby script? A bash script? A binary? Why is it called "rails" when the whole framework is called "Rails"?) and pass the arguments "new blog" (obviously this is creating something, but what? In most languages, "new" is a keyword that is usually used to create instances of classes - so is it creating an instance of something called "blog"? Does that mean that Rails knows what a "blog" is already?) To me - this is magic. Rails says "type this incantation and I'll do some stuff for you". Django says "here are some tools you can use to do stuff".

You might disagree with me entirely in this particular case - perhaps you find the Rails example clearer - which is fine. The point of this example is to say that framework and language preference is so intangible that the very first line of your documentation can sway someone's opinion either way. Instead of fighting against the "magic myth", you should just be trying to attract developers who like your particular brand of magic (or, alternatively, don't see your code as magic at all).