Getting by /without/ direct SSH root access is often impractical (think about scp), and without-password is a secure way to have it.
Also, the more people know about "without-password", the less people will set PermitRootLogin to "yes".
It's far easier to audit what's been done to the server, which is important not just for compliance but also for figuring out why something's broken suddenly.
It also means that you get to have your own shell history, your own shell settings, your own vim settings, etc, etc.
In general, having proper deployment, log collection and config management tools in place tends to mean you rarely need to scp files around at all - and the cases when you do, you can work around this by scping them to some other dir, and moving them locally with a sudo command.
A user login followed by su to root is a valid alternative, but I wouldn't have a problem with allowing key-only root access via sshd either.
You'd want the root key/password to be very tightly controlled for the reasons you mention, but having it set is (IMO) a worthwhile backup plan for when things go wrong.
I said "impractical", not "impossible". Of course I can use sudo. But it's more work. I require root access a lot. It adds up quickly.[2]
And I hate typing passwords/passphrases. In fact, many of my passwords I can't remember. I've got an SSH agent for that, which reduces passphrase entry to yes/no (tab-space/space, actually).[1]
Also, I prefer my normal user account not to be a sudoer at all.
Besides, please consider that disallowing root access actually only gets you protection against root password guessing anyway. The "stolen key + passphrase" scenario in a sibling subthread is so absurd I felt the urge to bang my head against my desk. Sudo won't help you there either.
[1] Now please don't suggest "passwordless sudo".
[2] And there is another inelegance: /home is usually on a different partition than /, so your way will involve an additional copy. If /home is even large enough to fit that file.
I understand you didn't say impossible, but this doesn't really seem to be impractical to me at all.
@Partitions: Seperating /home and / prevents normal users from filling up /. (And if you put both on LVM, you can grow them as needed.) Yes, I've only had this on some of the servers I've run.
@Impractical: it's one additional command for something I do quite often[4], and I still don't see the benefit (reminder: I fully agree with never using "PermitRootLogin yes").
[3] Granted, it does provide some context seperation in the sense that if you want to perform an administrative task, you have to explicitly use sudo. But it doesn't increase security, and it offers no advantage over "direct root access + normal user account".
[4] Not just scp, but also things like "less /var/log/messages" or "git clone root@host:/etc".
And again: what does "PermitRootLogin no" gain you over "without-password"? Why restrict it for no additional benefit?
Though direct remote code execution is probably much, much more likely than authentication bypass.
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.
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.
Passwordless root SSH is perfectly fine, which is why it is enabled by default. By people who have thought a little longer and harder about all this than you. (Sorry for the tone. Maladvice like yours on public forums is demonstrably harmful.)