HTML-CSS is the original output format for MathJax written 8 years ago, when the browser landscape was quite different. It involves a lot of browser-specific hacks to accommodate differences in the older versions of browsers. HTML-CSS has support going back to IE6, Safari 2, and Firefox 3, for example. Since then, a lot has changed with browser, and also with HTML and CSS themselves. The browsers are much more consistent in their implementations of the standards, and the coverage for newer features is more wide-spread. So CommonHTML was written two years ago in order to take advantage of that. One of the design goals was to make it be browser agnostic (i.e., no browser-specific hacks) so that the same HTML is used for all browsers (that is the "common" in CommonHTML). This necessitated dropping support for the oldest browsers, so it only goes back to IE8 (and that is a little buggy, so IE9 is the real lower limit), so that is one difference.
Another difference is that CommonHTML currently only supports the MathJax TeX fonts (not the STIX fonts or any of the other web-based fonts available in HTML-CSS). CommonHTML is set up to use a local copy of the fonts, if they are installed, or web fonts if not, but it does not go through the detection process that HTML-CSS uses to select a local font in preference to web based fonts. (This is partly because that process is fragile, and partly because we wanted to make it possible to use CommonHTML server-side to preprocess the math, and so you can't tell what fonts the user will have.) CommonHTML could be extended to use the other web fonts, but that hasn't been done yet.
Another difference is that in the HTML-CSS output, the bounding box for the complete expression is accurate, but the bounding boxes for sub-expressions are not (so setting the background color in CSS for some subexpression would not always produce the expected result). CommonHTML goes to considerable pains to make the internal bounding boxes be correct as well.
Finally, the HTML-CSS layout involved taking measurements of some subexpressions while they were being constructed (in the old days, this was crucial, since the different browsers' text handling could produce very different widths for the same expression). But taking those measurements was both time consuming (it caused page reflows), and browser-dependent (so made it not work server-side). The CommonHTML output doesn't do those measurements, making it faster, and browser independent.
These are some of the most important differences.
It's not that it is harder, it is that CommonHTML is not supposed to have any browser-specific hacks. That is an important design decision. They are just not allowed. So when there is a difference in how browsers handle HTML, one has to come up with a means of producing the desired output that works across ALL browsers (not a hack to fix one browser). Doing THAT is what is sometimes hard.
Davide