Perhaps I will regret using that tagline. It's an analogy covers half the functionality.
Tier does set up and manage your stripe account based on your pricing.json config, but we go further than that with metering, feature flag style entitlement checks, and other things we plan to provide that you couldn't do as just a provider.
There are terraform providers for DNS services, Database configuration, CI services and all sorts of other things. It's actually not that hard to write a something that wraps configuration state of various APIs into a terraform module.
Now, I don't really know the Stripe API besides a quick skim a few years ago, but I think that it's a fully reasonable comment and expectation that when someone says "Terraform for random API" one expects a terraform provider for that.
And combine it with cdktf you can use actual code, shared consts, and have a reliable setup in a common language rather than a JSON DSL.
Use HCL and you can use actual code, shared consts, and have a reliable setup in a fit-for-purpose (declarative) language rather than a JSON DSL.
Not sure why his comment was downvoted, but I actually think his comment is accurate. HCL is pretty limited in its primitives. In my opinion cdktf's two fundamental issues are:
1. the generated HCL contains plain text passwords if you use any sort of secrets access inside of cdktf
2. because you can use any programming language for cdktf, every project will look different. But then again terragrunt and terraform also have a bunch of differences.
Because the recipes still look like they're targeting a very technical user, which was my mental model for why one would build a whole new DSL