Your confusion stems from the fact that you do not understand what you are doing on Windows. On Windows, actual services are run from the Service Control Manager, and they have had the ability to run under the aegides of dedicated user accounts all along. A proper unprivileged service on Windows employs the username of a dedicated unprivileged user account, which the SCM logs in as in order to create the service process.
What you are doing, in contrast, is not running a service at all. You are running a program in your interactive logon session, in the background. And it isn't a terminal that you are using, it is a console.
The reasons for employing dedicated accounts for services are in fact common to Windows and Linux operating systems. Running services as separate processes under the aegides of dedicated accounts means that the operating system mechanisms that protect users from one another (Windows NT and Linux both being multi-user from the ground up, remember) also protect the service processes from you, an interactive user, and from other services. They likewise protect you and those other services from the service.
The multi-user mechanisms allow find grained access control on files and directories that the service program uses, prevent the services from being sent arbitrary signals by malicious processes, prevent the service processes from being traced using the debug APIs, prevent thread injection, and prevent arbitrary processes from being able to pause and resume threads. And all of these preventions work the other way, too, meaning that the service, should it be compromised, cannot do these things to others.
You are running a service that responds to requests across the network. It is designed to run under the aegis of a dedicated user account for these very reasons. It speaks a complex human-readable protocol that is non-trivial for programs to parse correctly, and could potentially be compromised if there were an error somewhere in that parser. But any attacker that succeeds in compromising it only gains access to your system as that dedicated service user, which you should have ensured has no unnecessary access to, or ownership of, files and directories that are not part of its intended function.
I myself extend this to the logging as well. Individual log services run with only the privileges necessary to access and write to their specific log directories, and are insulated from one another, from interactive users, and even from the (unprivileged) "main" services whose logs they are writing.
In a well-architected system, there should be scant few service processes that run with privileged access. Generally, they will be things that provide some sort of multi-user login, such as SSH or FTP services, where the major part of the service does still in fact run under the aegis of an unprivileged account; but it is simply the case that negotiating which account is an inherent part of the service function.
As such, you should now be thinking whether the gitea instructions are enough. The service account that you are creating is permitted interactive login via SSH, has an interactive shell program as its login program, and owns a home directory, giving a compromised service the ability to put stuff there and grant access to stuff there.
Further reading
