Right. To elaborate, the benefits he enumerates are really things that he thinks will be easier after a complete rewrite into a more modular design.
Based on his description of the current CS compiler, it looks like the meat of the compilation from CS to JS is done in one step. After it's parsed into a CS AST, the AST is walked, and each node knows what JS it corresponds to. It prints it out as a string, and voila, you have JS.
A more orthodox and more robust design would parse the CS into an AST, and then push that AST through a series of stages. Each stage would transform the AST and have a narrowly defined purpose (flattening, uniqueification, etc), which should bring the AST closer and closer to a JS AST. The last step would be walking the AST and outputting strings.
So, one benefit he mentioned is that you can "define multiple sets of (CS)AST -> (JS)AST transformation rules for multiple compilation targets." What this means is that since the entire transformation won't be done in one step, this will allow the modularization of stages. So, suppose there's some stage that's making the JS more IE friendly, but you don't care about IE. No problem. Remove that stage, swap in something else.
Having multiple stages will also decouple parts of the design, and lessen the need for special casing. So, hopefully less bugs and more extensibility.
He also wants the JS AST to conform to some Mozilla standard, so existing tools will be able to operate on it. In fact, it sounds like his strategy for printing the JS AST into JS concrete syntax is to use an existing project that operates on these mozilla ASTs.