Yes and no.
Would TLS meaningfully improve the security of this system?
YES, assuming you implement it in a good way. It certainly won't reduce the security, and can prevent some attacks. If the client is a thick app rather than a browser, you can quite substantially improve the security. However...
If I add TLS, will that make this system secure?
NO, even with TLS, loopback sockets are generally not a secure method of IPC. Besides, there's no good reason to use them in a system like this. Almost every other method of IPC is much more secure, and usually also faster, more reliable, and more feature-rich.
Do I need to put TLS on this loopback service to prevent sniffing of the plaintext password by unauthorized users?
Probably not (unless you have e.g. a network tap interface enabled with permissive access control). However, that's not the only risk.
Or, since only root (or processes with certain capabilities) can sniff interfaces, does this mean even without TLS, the password is already safe from all non-privileged users?
No, that restriction isn't sufficient by itself to protect the password, or the service in general. See more detail in the next section.
Also, depending on exactly what you mean by "plaintext password", this system might broken regardless of the communication channel. For example, it is entirely possible to carry out a timing attack for linear-time brute forcing of a password if you have local code execution on the server, even with very limited privileges (e.g. within a browser JS sandbox), so your app would need to be secure against that. Other, more complex side-channel attacks might also be possible. Finally, simple brute-forcing is a significant risk.
The main thing that TLS would add to this scenario is the ability for the server to prove its identity to the client (by passing a certificate that only the legitimate service has the public key to), before the user submits a password. Without TLS, you generally can't do that. In the specific context of HTTP[S], this doesn't even necessarily help, because HTTPS has no way to say which certificate you expect to find, and no public CA will issue a certificate for a loopback address, so it may be difficult for the browser user to distinguish between trusted and untrusted certificates.
Envision a scenario: the server crashes for some reason (possibly because a malicious user specifically threw a lot of garbage data at it to try and cause this). Before it restarts, the same loopback port is bound by another process - one started by a low-privilege user - and presents the same interface (including, if it's a web server, the same web pages). This fraudulent server waits for other users - including you, the administrator - to come and log in. As you do so, it silently harvests passwords, passing them to the malicious user. The user then kills the fraudulent server and waits for the real one to come back online, at which point they log in as you (or anybody else whose credentials they captured).
HTTP[S] is also particularly high risk due to all the cross-site attacks (particularly CSRF, and possibly also XSS and clickjacking) that you need to protect against. CORS, if enabled, is also very dangerous with local servers (unless you give them a "real" domain name and a trusted TLS certificate to match).
Loopback sockets are approximately the only form of IPC that don't offer any means of identifying either the client or the server, restricting what users can run either the client or the server (unless the server is privileged and listening on a reserved port, and the attacker lacks such privileges), or securing the communication against eavesdroppers or misdirection. TLS solves some of these weaknesses, but not all of them (unless you go full mutual TLS where both sides know exactly what certificates are expected and will reject any other outcome). Local / UNIX Domain sockets (on *nix or recent versions of Windows) or named pipes (especially on Windows; the *nix version of them works but has fewer features and is in general less ideal) are a much better option.
