I suppose automated deploy scripts could also be modified to accept an authenticator code as a parameter too.
I think you're misunderstanding. Two-factor authentication is a layer of security on top of regular authentication to ssh (whether password or key based). It's not meant to replace anything or stand on its own. This is for added security; first you authenticate via password or key, and then you authenticate via google authenticator.
If it is, it doesn't really add any security.
Morever, if the servers you authenticate too all share the same secret (ie you use the same token with all of them), you're decreasing the value of the 2nd factor by the amount of servers.
That's because anyone getting access to those servers can generate your OTP and connect to the other servers (if they also have the SSH key).
One way to mitigate that is to have a centralized authentication server for OTP.
All in all, if you want to protect your secret, OTP isn't the best solution. It's just something convenient. I would recommend using an openpgp smartcard instead.
I understand why and how this adds the extra security for the 'traditional' password authentication due to all the methods of compromising a password: brute force, guessing, exploits etc.; so for TFA to add an extra layer surely the private key would have to be exploitable in some form?
Maybe I phrased myself incorrectly in that I still see how it adds an extra layer of security but I fail to see why one would do this on top of a key based auth method.
I know the original article didn't mention using it on top of key auth but I wanted some insight as to whether or not it would be worth doing. As do many, I use TFA for any online service I can so I do appreciate its point in that sense.
EDIT: I never really considered the fact that the private key could be stolen via malicious software. Taking that into account I see the value in TFA for SSH.