Would you like to clarify how, from a security standpoint, the string "root" is worse than another user?
Allowing root login can be a user-management headache in multi-user environments, but strong SSH security can exist for root just the same as for any other user.
Because — LSMs aside — user commonly identified with a string "root" has unrestricted access to nearly anything and deserves additional security. This is also why NOPASSWD on sudo is not a good idea — even if your key leaked (bad things happen) and attacker got in, the system is hopefully still secure.
If you need to conveniently update some files on regular basis — chown or setfacl on them to your usual user or group. If you need to update root-owned file once in a blue moon — scp && ssh sudo mv it, it's not that hard, but better for security.
Oh, and obviously there are exceptions to the rule - say, if you're configuring some freshly-installed system and doing heavy config editing by hand (say, Puppet is not your thing or you just don't care about re-deployment), temporary lifting security barriers is perfectly fine in most cases.
Because a potential intruder is more probable to try "root" than "akerl_35" to get access. It's no big deal to login as any other user and then use sudo (if needed) or even su
If a potential intruder knowing what username to use helps them bruteforce your SSH, then the problem is with the entropy of your password, not your choice of username.
Yes, but it's easier to teach admins to never use "PermitRootLogin yes" "because it's bad for security" than to teach them to never use weak passwords.
Allowing root login can be a user-management headache in multi-user environments, but strong SSH security can exist for root just the same as for any other user.