Unfortunately, this is a scenario where github just misinterprets the distinction between a key pair and an account or project.
Since a key pair is used for authentication and authorization, it is effectively an identity. Github accounts are another identity. Connecting github accounts to key pairs effecticely establishes a 1:N mapping between github account based identities and key pair identities.
Conversely, github enforces a 1:N mapping of projects to key pair based identities. The real world analogue is that there is a door granting access to the project that can be unlocked by many different people. But once any of them gets a key to the door, they cannot get any other keys for any other doors, ever again.
It makes sense not to re-use keys often from the perspective of containing breaches if a key gets compromised. But that’s just a good administration policy. It doesn’t make much sense to prevent a key from being used more than once on principle. That there are some keys for some doors that are never re-used, well, again that’s down to policy.
A slightly more complex view is to illustrate key pairs as roles. You can possess many key pairs, and therefore inhabit many roles. The private key authenticates you for the role.
Github’s deploy key mapping to projects states that a role can never encompass more than one task. That’s rarely realistic.
None of which changes what github allows, of course.