if we had better buildfile tools than event assembler then it would be easier
i think we can generalize these two approaches to the "buildfile" ("source code"?) approach and the "in place" approach. Klok mentions the problem of "converting" to EA, but that's the wrong way to think about it -- you don't really "convert" an existing project to using an EA buildfile (you may s well just start from scratch). A buildfile is just "some computer-readable description of 'this is how i get my final project from the base ROM'". To "convert" a FEditor modified project to an EA buildfile would probably be a lot of work, since we'd have to come up with ways to serialize the internal FEditor data structures into EA-friendly data (work for this exists, but FEditor doesn't keep track of diffs so we'd need to figure out how to figure out what's in vanilla and what isn't).
It's also worth noting that these two approaches are not mutually exclusive -- you can write a buildfile on top of an existing working ROM perfectly well; this is how the most recent builds of EN were developed (with a buildfile that treated "the last EN revision" as "the base ROM"). It is much more difficult to do the reverse, because the whole point of a buildfile is that there is no working ROM, there's just "the base ROM" and "the buildfile".
Having a nice GUI is of course preferable to not having one, and having a tool generate EA buildfiles or something would be fantastic. What people are missing, though, is that having a machine generate these for you (even based off of some graphical representation of a project) by necessity requires making some assumptions about the project's internals, which is inherently less flexible. How is some prebuilt GUI tool supposed to understand how, say, Misaka's portrait mod works? Sure, someone could write that in now, but what if I (or circles, or colorz, or whoever) comes up with some radical new thing that changes how some other underlying data is represented? EM, or whatever would be completely in the dark as to how to serialize these new data structures (Lexou has talked about how it's possible to deserialize these by examining the in-ROM routines, but I don't think it'll be so easy to write a system to do the reverse for arbitrary data). Yeah, you can work around that somewhat by making your GUI tool expose some easy hooks for people to write their own modules, but we were already talking about how there's a shortage of tool developers?