However, my perspective is that Stripe sits one level lower on the infrastructure map than a service like Recurly (http://recurly.com) which is designed to abstract the pain of subscription management away from app developers. I use Stripe first and foremost as a best-in-class one-time payment processor. There's nothing stopping me from building a subscription management solution on top of Stripe; I'd just be re-inventing the wheel.
Stripe's subscriptions strike me as a good compromise between nothing at all and something that becomes more sophisticated over time. If they try to stamp out all of those edge cases, they will inevitably break someone else's application that relies on a slightly different interpretation of "the way things are supposed to be".
I sincerely hope that Stripe continues to say No to feature requests far into the future. Where does PDF invoice generation (with HTML templates of course) fit into "the simplest thing that works"? When Stripe notifies you of a sale, generate your own invoice. Maybe even consider open-sourcing that code. Adding it to Stripe is not the best thing to do.
Stripe offers a low-level API and a higher level API and framework can be built on top of that. So what we really need are some high-quality django/rails modules that deal with all the mundane bookkeeping. Then you can easily fork the module to make adjustments where needed.