As two people asked me to convert a comment to an answer, voilà:
The notion of an "easy to use, spits out the result GUI" is an "industry approach" where obtaining a result matters more than the minutiae of how said result is obtained.
For this group there exists at least one commercial quantum chemistry product from the Netherlands. I used a trial version and the automation actually irritated me... - There you built a molecule and the software would go as far as to suggest a functional and method.
"Input in, output out."
If we move to the quantum chemistry research field which is significantly bigger than industry use (at present), the users are either learning how to use quantum chemistry or are already experienced in it.
In this case you want to be able to explicitly control your inputs - maybe compare functionals, basis sets: a GUI can even be a hindrance if you like using scripts. (Its easy to run a benchmark when scripts do a lot of work ;).
Keep in mind that most calculations in quantum chemistry are relative and not absolute. You want to compare the difference between A and B, you need to be sure that A and B are calculated using the same methods.
Now an interface could accommodate all possible combinations, however once you attempt to cover all options, you arrive at an unnecessarily complex GUI. As a result, a GUI will often propose only a subset of options. The most frequently or well known functionals, commonly used basis set. If you use the GUI as a text editor, then its use is limited - especially if you need to know your inputs anyway. A light text editor is much faster.
(Look up the GMTKN benchmark - there is one from 2017 which evaluated functionals. How do you want to support all in a GUI in an easily usable manner? You cannot. Given the number of functionals that exist, documentation with a long list and a text editor is actually the best solution for experienced users. And then you need to update it every time a new functional comes out...)
The main interest in/reasons for using a GUI in quantum chemistry are:
- building the initial molecule (though you might even be running calculation son an existing benchmark set of xyz co-ordinates)
- visualizing frequencies (I do not think you can really understand the frequencies without a GUI, BUT you can easily calculated with the resulting values without seeing them.)
- visualizing for example an IRC calculation to verify that you have obtained the correct transition state.)
The vast majority of information that you obtain from quantum chemistry calculations are available in plain text in the output file, you do not need a GUI to read the value.
In some cases, you can even be unsure as to what the actual value in the GUI is... (There is a certain US product where I believe the GUI and text file provided different E0 energies, possibly shifted by the Zero Point vibrational Energy...)
So once again, if you are doing research, it is much faster to run a script to pull the values from the text file than clicking around a GUI to do the same thing. - Plus you know exactly what value you are getting from where and how.
Now it can be said that the output of some quantum chemistry code is atrocious in its formatting - mainly a result of the age of the underlying code and there GUIs invariably provide some benefit, but they aren't the perfect solution either. (See my E0/ZPE comment...)
Nowadays my favourite quantum chemistry code is ORCA, which, due to having a much younger code base compared to other codes, provides very clear and structured output that you are much better off accessing "as is".
This brings along another important question:
Should software retain the same file format when the limitations become more and more obvious? - If your output file is not easily usable, it makes more sense to update the output in a future release to be more legible, rather than creating software that attempts to interpret data displayed in an overly complex manner. (Typically a concise manner relate to limitation in Fortran several decades ago.)