There is the obvious issue with backwards compatibility there, although that can be overcome with work. The other major issue is that no WYSIWYG system is likely to be as powerful as wikitext, or as quick and easy to use (for experienced users). WYSIWYG is certainly much easier for new users, but once you are familiar with wikitext, it is generally better.
Actually, I don't think these are even the worst problem. The worst problem is that the wysiwyg editor would have to cover the full range of what wikitext can do now - and it would get very complex and hard in exactly the same places: a bit of text styling is simple enough, in wikitext, in a new parser, and in wysiwyg. But editing nested tables is already a challange with "real" word processors, not to mention web-based editors. And when we get into designing complex templates, using "magic" sections like noinclude, using complex parser functions and template parameters, and, most of all, using special constructs defined by extensions, things get extremly complex. For example, extensions could rely on xml represenations, but they would have to provide gui interaction elements to create and edit them. I truely believe that trying to buld a gui framework for this would be much much harder than all the tricky stuff a good wikitex parser has to deal with. With a "simple" parser, as well as with "naive" wysiwyg like fckedit, it's easy enough to get to 90% of what wikitext can do. Getting to the 99.9% we need to make this usable for wikipedia is HARD. And doing it as a gui system is harder, imho.
-- Daniel