I run multiple production servers, many of which have Java applications installed on them. To run a GUI on a Linux computer adds more than 100MB to the system RAM usage and that's 100MB I could pack one or more additional applications into. It's also much easier to log into a remote server using Secure Shell than to set up a remote terminal session - and in addition to my local farm, I manage servers in remote locations, including some at the exact opposite corner of the USA from me. Running a GUI over long-haul Internet can be less than pleasant sometimes.
Many of the services I run are managed via batch scripts. There's very little standardization in automated GUI control for that kind of stuff - plus a single GUI command line is a lot more efficient than having an automation push a mouse around what is often a series of dialogs.
But the question was "GUI for training". If by training, you mean learning
programming, you don't program graphically using a GUI, you program graphically using an
IDE. And there are many IDEs, ranging from the primitive non-GUI add-ons to the vi and Emacs editors (I've done Java using that), to the full-pixel oriented Eclipse, IntelliJ, JDeveloper and even the extinct Symantec Visual Café. There's no one "GUI" (IDE) that trains everyone.
In any event, I learned many years ago that depending on a GUI IDE to build software is extremely perilous. I got into a situation where in the middle of the night I had to make a 1-line change to a critical application, but the application couldn't be built with the current version of the GUI. You had do install an antique copy of the GUI and then apply a series of maintenance fixes to it. It could have been worse. The IDE version I needed might have required installing an older version of Windows and accompanying fix packs, in which case I would have had to wipe my entire system disk and spend 3-4 hours just getting to the point where I even
could compile this one-line program change.
And that's not even counting the fact that almost every GUI design setup I've run into was customized to the particular disk organization that the machine's owner had set up. I worked at a company where the official policy was that the different departments would be using common in-house resources, but in practice we couldn't because the resources in question required a completely different file structure than we had. Every time I'm tempted to curse
Maven's rigid directory name and location requirements, I remind myself of this and become grateful.
Because of that and similar traumatic incidents, I now have a firm policy that whether I develop an app under a GUI IDE or not, the production build MUST be done in a command-line environment. Tools like Maven and Ant aren't totally immune to obsolescence, but they are OS-independent (including OS version-independent) and like most Java products, they are designed to maintain backwards compatibility as much as possible.