Pierre from Kill Bill here. This sounds like something that is be supported out of the box. I'm not sure I understand why the Stripe plugin needs to be rewritten, but feel free to reach out to our Google groups if we can help!
It really depends on your usecase, but some benefits:
* Lower cost (just pay for payment processing, not the subscription features)
* Ability to integrate with multiple gateways (to lower cost, support more payment instruments, higher resiliency, etc.)
* More advanced subscription features
* Ability to customize the system through custom code (plugins)
* Data ownership (easier to run analytics reports, since you own the subscription data)
FYI this is just a managed sandbox, to test things out. We don't offer Kill Bill aaS, as it goes against our value proposition (Kill Bill is a framework to build your own internal subscription billing and payments platform).
FWIW the very vast majority of our users are integrated with either Adyen, Braintree, or Stripe (all open-source plugins).
I know of ~20 integrations with more advanced gateways/processors: these are closed-source plugins, but the overall community wouldn't benefit much from accessing them (e.g. it doesn't make sense for many companies to directly integrate with mastercard APIs).
Kill Bill (note: I'm a co-founder) provides payment routing capabilities, so you can integrate with multiple providers (e.g. Stripe + Adyen) and shift payment traffic to go through one or the other dynamically. This is very common in large b2c companies.
That being said, to your point, this still requires either a vendor neutral vault for the cards or to tokenize them in all of the vendors. Possible, but still hard to do in practice.