There are many cases where you do not want, or cannot have a password protected ssh trust. For example, say you have a central nagios host monitoring a network, that nagios host needs to connect to remote machines to run interesting monitoring scripts (disk % full, raid controller query, mpio checks, etc), in these cases you do not want to have a password blocking the ssh trust. You will also find this type of thing happening in many continuous deployment workflows as bits are moving from one machine to the other. This is very common practice.
In that case, you would lock down the key so it could only be used to execute the strict subset of commands to do its job. It is very common practice, but is not mentioned at all in the blog post.
That does indeed sound like such a case. However, none of these cases appear to be what the article is addressing; it's just telling you to use non-password-protected keys, with absolutely no discussion of it.
These sound like exactly the cases where you shouldn't use ssh. Use nrpe instead, or run the check on the target machine from cron and make it report back. There's no reason to use ssh for it and at scale ssh adds considerable load to the monitoring host when starting the connection.
For continuous deployment you can't easily work around using ssh, but at least the access can be limited to specific commands only.
