(a) your old key should sign your new key
(b) write a transition statement, stating that you're moving from
an old to a new key, and that you want your new key to be signed
(c) sign that transition statement
Isn't the act of signing another key that has the same UID/email
address, sufficient to prove that all trust placed in the old key
should be inherited by the new key?
No. Signing the key only will only provide whatever trust metrics are determined by another user's trust policy once they import that key.
That is: (a) is sufficient, (b) is perhaps useful (though could be
replaced by other unauthenticated channels), and (c) is
That won't achieve the aim once the information is received by other OpenPGP users and the effectiveness will vary entirely according to their own policies. If you only sign your new key with your old key then the new key will only gain whatever trust values, usually at a somewhat reduced value flow on from that signing. Those trust values, however, are not determined by you, they are determined by each user within their keyring.
An easy demonstration of this, of course, is to compare the trust value of your own secret key to anything else in the public keyring; yours should be "ultimate" and all the others will be less than that. Chances are most of them will be "unknown" or otherwise not specified.
If you only sign your new key with the old one then there is essentially no difference between that and any other key you sign, such as following a key signing event. The purpose of a transition statement is to explicitly confirm that the new key replaces the old key and that anyone who signed your old key should be able to use the statement to confirm the transition and sign the new key. Which is not something they would do for any key you happened to sign that does not belong to you, regardless of UID conflicts (which may or may not always contain email addresses).
In order to provide the necessary assurance and relevant information to people to whom you are essentially sending a request to sign your new key, you really should provide all of the information. I'd say "must" here, but I don't want to confuse people by using RFC-like terminology.
One thing that is normally recommended with transition statements which has not been included in your list above, however, is that
(c) sign that transition statement ought to be dual-signing the transition statement. That is, the transition statement document is signed by both the old key and the new key.
A few years ago I transitioned from my old key (0x371AC5BFA04AE313) to my current key (0x321E4E2373590E5D) and used this transition document) which you can see the whole process with. If you import both my old and new keys and then verify the statement you'll see that the signature data contains two signatures rather than one, though with the same timestamp. The transition statement contains all the necessary information to verify a key which would normally be verified in person or via some other trusted channel (i.e. usually at a key signing party or CryptoParty), the dual signature tells recipients that both keys remain under the same person's control and that they do not believe the old key has been compromised at the time the transition statement was made.
You'll also see that I nicked the majority of the wording of my transition document from DKG. ;)