For a long time, these corrections will be needed. However, it doesn't hurt to dream: what use, if any, is there for a GUI in a decompiler that has good analyses? Sure, all analyses can fail, but in those cases, might it be better to just fix the limitation in the decompiler, and leave it as a batch processing program (i.e. no GUI)? Or perhaps have a GUI, but just to amuse the user and/or allow the user to browse the results before the analysis is finished?
Well, it turns out that there are still some valid reasons to want to have a GUI anyway, even if he analyses are very good. Many interesting questions in decompilation (and in compilation and any other program transformation or even visualisation) are equivalent to the halting problem, and so cannot be answered in the general case. Compilers avoid this problem by simply not performing certain optimisations when they are not safe. Decompilers have to make other conservative actions, such as putting a variable into the set of address-escaped variables even if in fact nothing uses that address to change the value of the variable unexpectedly. Such variables cannot be propagated, since aliases may cause the propagation to change the semantics of the program. Not propagating the variable can result in a less readable program, sometimes very significantly so. So if the GUI can in effect tell the decompiler "this apparently safe operation is hereby declated to be safe" (and if it is not, well the user asked for it!).
So here is partial list of things that a GUI could be used for: