That is to say, in what cases does it make sense to commit an unencrypted keypair to internal source control like SVN or Git?
Related question that discusses an encrypted private key: Is it bad practice to add an encrypted private key to source control?
In general mixing code and secret configuration (passwords, keys etc) in the same respository is a bad idea because generally a lot more people need (or at least would benefit from) access to the code than need access to any given secret. Also the common workflow with VCS systems is to create lots of copies.
That doesn't mean you can't put secret configuration in a VCS but it should be a seperate repository from your code and access to it should be very tightly controlled.
When the private key is nothing more than a test fixture used to test some process requiring a private key and where the private key is not actually used to secure any system.
In some cases it can be appropriate to commit an encrypted key. For example if the repository is public/open source but a Continuous Integration system requires access to that file - Travis CI supports this.
Otherwise you shouldn't commit private keys.
I think what you need to ask yourself is:
If the key gets compromised, can I detect it?
and
How does the revoking process affect other people?
For example: what if the internal source control repo is taken outside of the company perimeter, e.g. via a developers' laptop? What if this laptop is stolen? What if it's a disgruntled employee that makes a copy and keeps it on their personal laptop?
In other words, can the key be used to access a public resource and if so what is the damage?
If your development practices require the sharing of a private key, then it is not a private key by definition. You might want to think about why this is happening and whether you should consider per-user access token (e.g. oAuth, an API key) or other solutions.
Since this answer hasn't been given yet, seems I need to:
Never ever. Really never.
As already pointed out, by definition a private key should be kept secret. But source control is made for sharing and making information available (maybe for a limited audience, but anyway).
The reason why you might want to do that is just because you haven't to the processes you need to have in place. Even though you might intend to use that key for some test system which will be erased after every test run, you probably do not enforce your intentions. Intentions will decay over time and at some point in time the key will be used in production.
When doing cryptography analyses for things like Man in the Middle attacks, it is typical to define the parties by their knowledge. So techniques to allow Alice to talk to Bob and allow Bob to trust that the message came from Alice define Alice to be "someone who knows everything important that Alice knows."
By putting the private key in the repo, you must now do all of your security analyses where the private key is now a private key to "everyone who could download the repository or otherwise get a copy."
If that level of security is sufficient for your private key, then you can put it in the repository. Otherwise, putting it in the repository will invalidate any of your security proofs that depended on the private key's dissemination being narrower than that.
