Yes, you're right — I wasn't being sufficiently clear. MathJax is indeed a rendering system which takes an input format (TeX, AsciiMath, MathML and possibly others) and converts it into a chosen output format (HTML (with CSS) — effectively a hodge-podge of spans, SVG, or MathML — yes, MathML is both a possible input and output format).
Technologically, it makes sense to directly compare MathJax with native MathML rendering. For example, take a document containing MathML and compare how it renders in Chrome with MathJax enabled (where the MathML has to be converted into HTML, in order to be displayed) and in Firefox with MathJax disabled (so the MathML is directly rendered by the browser) — Firefox will be much faster.
From a social point of view, we can compare our world to one in which most browsers can competently render MathML. In the former, people creating webpages/writing comments on the web, containing maths, will, say, write some markdown with embedded LaTeX, and use a server-side processor which converts the markdown to HTML, leaves the LaTeX alone and includes the MathJax engine, so that the LaTeX can be rendered client-side. (Since they have to include MathJax anyway, they probably won't bother with the extra step of converting the LaTeX to MathML server-side. Hence, even browsers that could render MathML, will still need MathJax for the LaTeX.) In the latter world, the same person, writing the same document, would instead use a server-side processor converting both Markdown into HTML and LaTeX into MathML, and no longer needing to include MathJax. The complexity for the writer/publisher would be the same (or if you were using LateXML or TeX4ht, lower), but the experience of the reader would be much, much better.