Hi,
The main reasons are
* The HTML-CSS output is highly browser and client dependent. From basic things like installed fonts to tricky things like hacks around browser and OS bugs, MathJax does a lot of work to guarantee identical display across all browsers. So in a very real sense, you cannot store the HTML-CSS output -- as soon as it gets somewhat complex, it will not render well across browsers.
* Responding to the client. The basic example is MathJax's line-breaking algorithm; without the context of a client you cannot provide very good linebreaking. Similarly, MathJax matches the ex height of the surrounding font (which will very likely depend on the client); without this matching the results can look rather poor. Finally, a user might use client-side extensions (e.g., stylesheets for readability) in which case pre-rendered content will easily break.
* Accessibility. MathJax uses MathML internally and can expose this to screenreaders such as MathPlayer and ChromeVox, including advanced features such as navigation and synchronized highlighting. Whenever you render mathematics into static output that is not MathML, you'll be doing the serious damage to your content.
Still, there are scenarios where pre-rendering is a necessity, e.g., JS/MathML disabled environments such as feed readers and ebook reading systems. Similarly, you can use pre-rendering as a preview mechanism for MathJax to enhance the user experience (MathJax can replace images on the fly to provide progressive enhancement). For this, you can leverage MathJax's SVG output (and the upcoming CommonHTML output) which is browser-independent. Check out
MathJax-node which was build for such situations.
Regards,
Peter.