Remember that a big part of our strategy is to write an API that anyone can implement and interoperate with. We expect lots of people to be implementing that API in the next few months. I personally think the majority of issuances, long-term, will come from hosting providers who have integrated our API. Starting with short certificate issuances means implementers are more likely to emphasize automation, and automation is one of our key principles.
Another pro: both Let's Encrypt and its Subscribers need to gain operational experience with automated issuance. This is a new thing we are doing, and it will take practice to get good at it. With renewals once a year, it would take many years for the TLS ecosystem, on both sides, to get good at automating issuance. Renewing six times a year gives everyone more practice, and we will get good at it more faster.
Like any good web service, we plan to scale to keep ahead of our growth, and we have a very generous window for the first year or two. But of course, we are a non-profit with limited funds, and highly dependent on ongoing funding in order to grow. And we may very well wind up issuing certificates for a large percentage of the web within a few years. Without going to far off-topic, my main concern when I talk about capacity is making sure that the capacity we have is allocated fairly and not spent on unused certificates, which is a big risk for a free service. There's a whole other thread to be had here!
Yes, this is definitely an important benefit. As Eric Mill put it, we need to turn issuance and installation from an emergency into the routine. That's a big part of why Let's Encrypt cares so deeply about automation.
This isn't a policy we can change. It's established by the Baseline Requirements, and for a good reason. If an earlier certificate was revoked due to key compromise, it would be important that clients be able to get that information. And, as @motoko said, some deployments use a unique private key per frontend.