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.)
The utility of a user interface further directly depends on the complexity of the input.
Standard "Gaussian type functional" quantum chemistry has today become (in many forms of its application) trivial and standardized with xyz input and ouputs for geometries.
(Yes, I know that metals and heavy atoms require a careful choice of method from functionals to basis sets.)
In contrast, setting up a quantum chemistry simulation for periodic systems using plane waves benefit a lot more from user interfaces. While it is easy to specify a "trivial" structure such as for example solid diamond based on literature parameters, the investigation of real life crystal structures (maybe with adsorbents) benefits tremendously from assistive software. I looked at plane waves briefly a good 10 years ago - and defining a good input is already a non-trivial subject. (Also the fact that neighbouring cells interact, etc. etc.)
Back then I was shown a specialized GUI in another department - which helped them define their systems. - And these softwares are not cheap as far as I am aware. On the free side I am aware of only ECCE (for NWChem) and VESTA.
Another field that benefits a lot more from user interfaces is Molecular Dynamics. While I'm sure experts can configure these easily from text files once the initial configuration is done, developing the initial understanding is not trivial. However as far as I am aware, in the case of GROMACS, the input has changed multiple times in incompatible ways between versions...
(Again, about 5 years ago I looked at Molecular Dynamics and failed and stuck to my Gaussian type functionals/calculations that I know how to do.)
As far as I am aware there is maybe one major Molecular Dynamics interface that can be had for free (for academic use) which is VMD. After that, the interfaces that exist are often commercial: Potentially because we return to the previous point. Industry wants results (and Molecular Dynamics if of interest in the pharmaceutical filed) while scientists want to understand the system and thus often want to modify minutiae in the configuration.