I mostly agreed, and tried to make progress on this topic in 2006, coming from an accessibility point of view.

However, I think that for many situations a well configured WYSIWYG / WYSIWYM editor is better than wiki-style syntax (e.g. for images and tables). A few things that help with that approach:
– Removing ‘style’ buttons, and making the structure ones primary.
– Including a pre-defined styles drop down that adds classes to certain elements.
– Using within-editor CSS to make things appear similar (in size and colour) to the published versions.
– Using within-editor CSS to add structural labels to each element (example).
– Using customised pop-ups relevant to your CMS.

You could probably do a similar list of things that would help wiki-style editors, which means there isn’t an ideal solution for this yet.

I suspect one-size will never fit all, some things are better as structured data (taking the form approach), some things are not very structured, and some can be inbetween (e.g. a pop-up that inserts microformated content details into general HTML content).

If anything, HTML5 makes this whole issue more complicated because there are no ways of taking advantage of HTML5 elements. The guy behind the Xstandard editor even wrote Why do WYSIWYG editors hate HTML.

However, how valid those points are depends on how much you think you should rely on an editor to do those things.