I don't know, judging by my SSH logs it seems a lot of the automated malicious login attempts are looking for common software used to deploy code. Knowing that a target machine has a username used by some popular software might be valuable information in an attack.
But on the subject of passwords, best practice for SSH for a long time has been to disable password based login entirely and rely on keys.
Exactly - it also works for non-SSH accounts, thus allowing software enumeration by testing for default/common/known default service users.
For instance, an OpenBSD box running Tor may have a user "_tor", a Debian-based box (e.g. Ubuntu) may have a user "debian-tor", and so on (depending on how Tor was installed, in my case via pkg_add & apt-get; usernames might vary for different OS/repo versions). I have tested this using the PoC against some of my own systems (the ones that have PasswordAuthentication still enabled) and it works for those.
...and apparently the same issue exists in Dropbear up until current version (2018.76 / Feb 2018), which has an entirely different code base. A comment on /r/blackhat [0] led a colleague and me to look at Dropbear's sources, and it happens to have logic that is sufficiently similar [1] for the same PoC to work; tests against v2018.76 and a couple of earlier versions (e.g. v2013.58) are successful.
Shodan shows some 66k services identifying as SSH-2.0-dropbear [2], as opposed to some 15k identifying as SSH-2.0-OpenSSH [3].
But on the subject of passwords, best practice for SSH for a long time has been to disable password based login entirely and rely on keys.