The hint of why this may be just slightly complicated is in that final phrase.
The hint is that they are putting the cart in front of the horse, have decided on an outcome, and now are busy working towards that outcome.
ssh isn't less secure, and yet you can just copy-paste the required files on your own, instead of relying on convoluted protocols for moving data between black boxes.
It reminds of of their "Data Transfer Initiative" which "let's people move their data around easier" but underneath it's just "well, some of data between Google Apple and some other third party services only": https://dtinit.org
Designing a system that is secure, scalable, and works for billions of people worldwide in a highly adversarial environment is freaking hard.
You're lumping together the data and access that SSH keys protect (which might be actually nothing) with the key mechanism themselves. The private key itself can be armored or stored in a Yubikey itself, or you can even use more exotic ways of protecting it.
The public keys can be easily automated while the private keys stay safe somewhere. Systems like SSH Universal Key Manager or Userify are out there (both on-prem, and Userify also has saas) to make maintaining the public keys across huge swathes of servers relatively simple (or sometimes extremely simple).
And not just authentication, but authorization, too (usually through something like sudo or doas). Or you can just roll your own with Ansible or LDAP (not nearly as flexible when dealing with two axis of variations - users and servers, but still doable). SSH keys being easy to manage is extremely important, because when things are hard to manage, people open security holes, either through ignorance or to save time.
So, like all keys, yes, SSH keys can be a massive security liability if not properly secured, but they're not so (intrinsically), or even by default.