Although I'm still not overly familiar with the term QA Engineer, I'll answer this as a quality assurance analyst who is passionate about test automation. I'll also attempt to make it understandable.
It is definitely a misconception that I personally understand. Jobs' link rings very true as it was an amazing answer.
Most of this misconception comes from the fact that QA engineers (QA for the rest of this answer) do not tend to write application code. From the normal end user perspective, our code does not do anything. I can certainly speak to this, as, I consider myself decent with automation code, however, I still struggle writing what could be considered an actual application.
One other misconception that even many developers have, is that QA's are considered to be nothing more than script kiddies. To a point, this is true. Without the actual application under test, our code will fail. This also plays into Justins answer regarding specialization. I've met more than a few developers who can't wrap their head around how test automation works, or even why we would like to write it.
I suppose that there's also the fact that at many companies, test automation is something that is considered to be a nice to have, and spend the bulk of their time doing manual testing (raises hand).
The final point, some companies drill this into misconception into their QA's heads. I've worked for a few companies, where, if QA wasn't required for compliance, the Business would rather save the salaries and hire more software engineers/developers.
The fact of the matter is, however, that you're right, most QA's who spend time with test automation are on par with their developer equivalents. More so, I always smile a bit whenever I see a QA teaching a developer coding practices, or how to properly use a method, etc.