Remember how Windows applications mainly worked back in the Win16 days before Win32 came along and did away with it: where there were
hPrevInstance, attempting to run a second instance of many applications simply handed things over to the first instance, and this made things difficult for command scripting tools (like Take Command) because one would invoke an application a second time, it would visibly be there on the screen as an added window, but as far as the command interpreter was concerned the child process that it had just run immediately exited?
Well GNOME has brought the Win16 behaviour back for Linux.
GNOME Terminal is now a client-server application. The
gnome-terminal program is just a client that constructs Desktop Bus messages to a server, passing along its command line options, environment, working directory, and arguments, and then simply exiting. The server is
gnome-terminal-server which registers as
org.gnome.Terminal on the Desktop Bus and which is responsible for all of the actual terminal emulation and displaying the window(s) on the GUI(s).
A Desktop Bus client like
gnome-terminal locates the Desktop Bus broker via an environment variable, which usually points to socket in a per-user directory such as
/run/user/1001. Alternatively, the environment variable specifies to look in "the current user's runtime directory" and a path similar to the aforementioned is constructed from the client process's effective user ID. This directory in either case is conventionally private to the individual user, and inaccessible to other (unprivileged) users.
Hilarity ensues when people attempt to run
gnome-terminal as another user via
sudo and suchlike. If the environment variable points to an explicitly-named runtime directory, an unprivileged client cannot connect to the per-user Desktop Bus. If the environment variable points to "the current user's" runtime directory, it looks for the wrong Desktop Bus broker, often the one for a user that does not currently have a Desktop Bus broker running because the user has not logged in and started up that user account's per-user services. (Per-user Desktop Bus brokers are run by a per-user service manager. The per-user service manager is either started explicitly or, in the case of some service management softwares, by some rather ugly hooks into the user authentication process employed by the likes of the
su, and SSH server programs.)
The reason that
dbus-launch worked for you as the superuser is that
dbus-launch explicitly launched another Desktop Bus broker, running as the superuser, which
gnome-terminal was able to talk to. Luckily, the system was also configured to demand-start the
gnome-terminal-server server when the client attempted to connect to it via the broker. (This is not necessarily the case, and nowadays such demand-starting is seen as an inferior mechanism as it ends up with lots of Desktop Bus server processes that aren't running under any kind of service management. Indeed, not having the broker itself under service management is considered inferior too. It's also generally not considered a good idea for the superuser account to have these sorts of services running, as many of them do not expect to be running with superuser privileges because they expect to be running under the aegides of ordinary user accounts.)
Further hilarity ensuses if, as the questioner at "How can I launch gnome-terminal remotely on my headless server? (fails to launch over X11 forwarding)" does, people attempt to run
gnome-terminal when even the original user does not have a Desktop Bus broker running. This happens when, for example, one has logged in via SSH but the SSH login process does not start up the per-user service manager, which in turn means that the per-user Desktop Bus broker is not run, and the
gnome-terminal-server server cannot be reached over a Desktop Bus. (According to how the system is configured, graphical login could still trigger starting the per-user service manager, and hence one might observe that logging in graphically as the same user magically makes things work. And again
dbus-launch would explicitly start a non-service-managed Desktop Bus broker.)
Yet more hilarity ensues when one has one of the service managers that has the hooks into
su, and the SSH server. These hooks usually implement the semantics of starting up per-user service management, and all of the per-user services that it starts, at first log-on for that user; and stopping them all at last log-off for that user. If one has a lot of short-lived and non-overlapping SSH sessions, then there can be a lot of overhead generated uselessly starting up and shutting down the entire per-user service management system (and all of its auto-start services) at the starts and ends of each of those SSH sessions. systemd, one such service manager, has an imperfect "linger" mechanism that only really half addresses this. It means that per-user service management "lingers" after the final log-off, but it does not stop the per-user service management from being started at all.