While Raph has a few good points in his most recent blog, I can't help but be more pragmatic.
When we examine real-world use cases with regard to handling MSWord documents (most importantly in places where MSWord doesn't exist), I've come to the following 3 use cases:
1) Viewing: User wants to view the content of the document. Formatting doesn't have to be lossless, as the formatting is generally grossly secondary to content. An intermediate format such as HTML, TeX, or plaintext will serve well here, as they pass the "close enough" test.
2) Editing: User wants not only to view the document (ideally in a lossless fashion) and be able to remove and append content as necessary. The intermediate format would have to be losslessly interchangable with MSWord, and the layout engine would have to produce (nearly) identical results as MSWord (whose layout engines aren't even truly compatible between version releases). Here, you want a tool such as AbiWord, OpenOffice, KWord, ... These tools all have the ability to do WYSIWYG printing, and are thus able to produce PDF and PS versions of their contents. Note that these tools aren't perfect yet, but do a good job and can be readily improved upon.
Raph conjectures that it might be useful to have a third option:
3) View losslessly. Layout engine would have to produce identical results to MSWord (see above #2 caveat) and produce an image of the document. PDF, PS, PNG all are good output formats for this use case.
Now, as far as most end-users (secretary, student) are generally concerned, the third use case hardly (if ever) exists or applies. However, in a server setup, it might be useful for #3 to exist for things like batch processing and archival. So let's keep it in for now.
Now note that #3 is a strict subset of #2's capabilities once you have a '--print' command line argument or similar interface. Raph concedes this. Now, if you believe cuenca's recent entries, you'll see that adding editing capabilities to a PIECE TABLE isn't too difficult on top of a static model. To boot, several static and dynamic piece tables have already been written and are freely available. The layout engine's *sole* purpose is only to render the contents of the piece table. The GUI uses a View to alter the piece table. Dynamic content is now not a factor whatsoever in the argument. We have shown that in theory AbiWord's (or OO's, ...) piece table and formatting engine should be able to be isolated from the program, and used in such a batch formatting engine, like one that Raph proposes.
Now, true, the advice Raph gives is sound - the best test for any new layout engine would be to use it + your piece table + graphics class as its own batch renderer. While this is useful for testing, development, and debugging purposes, I think that it's worth the little bit of extra effort to slap a MVC architecture on top of it and make it editable via a GUI. IMO, it'd be a shame if you didn't.
IMO, creating your own renderer now would be useful for novelty alone, as there are already several quality existing ones. Not that there's anything wrong with novelty. I wouldn't expect to get it right anytime during this lifetime, though. I'd personally rather have you working on Abi or OO. But it is your time to spend as you please. In my ideal world, #3 only exists as a step to #2, and #2 already exists in several incarnations. YMMV.
Finally, using The Gimp vs. ImageMagick is, in my opinion, a poor and flawed analogy. Tools like IM (as described here) turn an image to a RGBA buffer. No layout-like operations are necessary during this conversion. The Gimp's operations place more RGBA paint on top of an existing RGBA canvas at specific (X,Y) positions. Again, no layout-like operations need to happen here. While it is useful to first have the "gimp image library" be able to decode the images into RGBA buffers first, the levels of complexity regarding what needs to happen with MSWord aren't even *near* comparable. They're apples and lawnmowers.
Does it make sense for #3 to exist? Sure, I guess. Does #3 already exist? I believe so, via #2. Should you feel compelled to write your own #3 instead of improving the layout engines in #2? Well, that's for you to decide. I'd strongly advise against it. But that's probably just my pragmatism, experience, and desire to have more people on my own projects speaking. IMO, there's isn't the diversity necessary within the OSS community to support multiple #3's (except maybe vanity). But that can be said of a lot of OSS projects nowadays.