Your main question is:
Problems with H can weaken the scheme; this is why people stopped using MD5 and are moving away from SHA1. So why not just skip step 3 and encrypt c directly?
Yes, MD5 can currently be broken in about 224.1 guesses (24.1 bits of security). SHA1 currently offers about 80 bits of security against the same attacks. You're claiming that dropping the hash entirely and getting 0 bits of security is somehow an improvement?
Your understanding is close, but you seem to be missing a few core concepts.
@LieRyan's answer gives the direct answer: that asymmetric crypto like RSA can only operate on fixed-length input.
To expand on that, you said:
[the certificate is] usually much shorter than the page content which my browser will presumably decrypt anyway.
You are mixing together a whole bunch of different misconceptions here and comparing apples to oranges.
What you are describing with "encrypting the hash" is called an RSA signature. I'm squeemish about even calling it "encrypting the hash" because technically you are decrypting the hash using the decryption key.
In practice real Certificate Authorities use Digital Signature Algorithm (DSA) or Elliptic Curve DSA which are based on completely different math, and can definitely not be described as "encrypting the hash".
Comparing the running times of "decrypting the hash" (aka "verifying the signature") with the running time of decrypting the content of the web page is apples and oranges because the signature is done with an asymmetric crypto (RSA or Elliptic Curve Cryptography (ECC)), which as @LieRyan said, can only encrypt a single fixed-length block, whereas the content of the web page is encrypted with symmetric cryto (usually AES) which is designed to encrypt / decrypt bulk data very quickly.
Ignoring all of the above, there's still a good answer to the question:
So why not just skip step 3 and encrypt c directly?
Because this would be much easier for an attacker to spoof. You are proposing that the webserver provide an encrypted version of their certificate that I can decrypt with the CA's public key. As an attacker I can change a byte of the ciphertext, decrypt it with the CA's public key and see what it says, repeat several billion times until I have what appears to be a legitimate certificate from that CA claiming that I am the owner of the website (ie the public key is one that I own).
Adding in a hash to the process stops that kind of attack because you've also got to check what the hash pre-image of the modified ciphertext is, and try again if it doesn't match. By adding a hash step, we've cranked up the cost of performing this attack from "a couple months on a laptop and ~$10,000 in electricity" to "centuries on a supercomputer and a power-plant to size of the sun".
(I'm only slightly exaggerating - assuming we could do single-electron computations, just building a counter from 0 to 2^256 would require energy equivalent to half the matter in the Milky Way galaxy).