Never login as root… even over secured links!
In other contexts you want to avoid shared root accounts, as you'd want to block access for former employees, but you don't want to rotate credentials every time. SSO for tailscale makes that easier.
Root makes everything more easier, for example to copy a file on a server with scp if you don’t have root login you first has to copy it to /tmp and the copy it in the right directory by logging in as normal user and elevating with su/sudo.
Also you have to remember which username was chosen when the server was installed, was it user, admin, or pi, or some default?
I get not using root for everyday usage on a desktop, but for a server having a non root user is not that useful.
Of course you have to know what you are doing, but sudo doesn’t protect you from stupid mistakes anyway (especially if configured with NOPASSWD as I always see doing because having to continuously type the password is annoying and password tends to be forgotten)
And this is naturally in conflict with being productive. As you mentioned, it's easier to be productive if you can just do all of the things all of the time. And operating in environments where a mistake may not be that devastating, or compromise or vulnerability this might be a reasonable tradeoff.
But I've worked in environments where this is too risky. For example: 1. Engineer accidentally pastes the wrong buffer into a terminal. They had accidentally copied some other piece of text. 2. The text happens to contain \nhostname set\n. 3. The terminal as it's spitting out errors, does see a valid command, to change the hostname. 4. That particular system was an HA system, and the process monitor in use, grepping the running processes for the command + args, of which hostname was an argument. And decided the process was no longer running. 5. The cluster seeing the failure, decides to boot another process. But at this time in history, that process was could only handle a single instance. Both instances now decided to conflict with each other. 6. Some part I don't remember about the failover site. 7. A million cell phones can no longer get an IP address.
So it's a question of tradeoffs, but is a generally recommended practice to not login directly to root, and operate with less privileges when not required. And then escalate if granted / required.
Ed: although in this case the binding between a system user and a person happens at the tailscale level.
If you ssh in, no matter to what account, your key ID is logged and that's what matters.
Anything can happen afterwards, unless you have a really tight grip on your system, since local privilege escallations are not that hard or uncommon.
Tracking actions, fine grained policy controls, sharing a root password amongst multiple people, and then there is the risk of accidentally running a cmd as root when you thought you were in your home shell!
I get the other points, but most servers I encountered don't have these fine grained controls because doing manual work on them only happens for debugging or fixing issues.
And the password doesn't need to be shared with sth like Tailscale.
Tracking actions is a good part though, I wonder if you can still track which tailscale user was responsible for that root login.