The real thing is does though is give you higher-level object-oriented constructs with best practices baked in. It has much more sensible defaults baked in and, almost ironically, the fewer parameters you pass to these classes the more opinionated CloudFormation comes out.
The example that blew my mind is if you don't specify a password for RDS it provisions an AWS SecretsManager Secret, generates a random password and puts it in there and then tells the RDS to use that Secret. If you do specify a password it doesn't do that stuff. Lots of stuff like that - it turns encryption on by default and creates the keys if you don't specify, it creates private subnets and a NAT gateway for VPCs if you don't specify.
It was basically "its too hard to fix the service APIs or their CloudFormation so we'll fix the problem outside of / on top of them with a tool users run on their laptops or in their pipelines to deal with generating the thousands of lines of CF boilerplate that are required to really do the right thing these days.
Of course you can be very explicit in most of these constructs and the more explicit you are about what you want the less of its opinions happen.
I personally agree with you about CloudFormation. I dislike everything about it.
I think the people who build the Terraform and Pulumi ecosystems are plain and simple better architects than AWS employees.
I make that relatively blind assumption because I've done an interview for AWS. They optimize their hiring process for hiring blindly loyal drones. They want you to memorize company values and relate everything you've ever done to each and every value. They make you read them off a list one-by-one. It felt so dystopian to me.
AWS seems like the last place a creative, talented developer would want to go. The phone screen would scare most of them off.
Pulumi does less "magic" than CDK, though they're working on higher level constructs, but ultimately it's just the better technology.
This is an absurd and simply untrue statement. Many teams at Amazon deploy their production AWS infrastructure with CF.
On the contrary, I have seen many many destructive terraform applies that really messed everything up - without a helpful support team to call (unless you are paying Hashicorp) that can just get you out of the jam.
Yes it is a bit slower and often you need to wait for it to rollback when something goes wrong - but 9 times out of 10 that rollback succeeds. I'll take that trade-off...
Pulumi bypasses CF by making and breaking the resources directly. The focus on cross cloud and multiple cloud means you're thinking in higher order abstraction but you lose the finer knobs unless you break the indirection.
CDK has ways to integrate directly into CodePipeline and use its own abstractions directly (such as with ecr or s3 deployments). Pulimi half expects you to have solved your CI/CD on your own.
Reliability is a different problem. System shits its pants halfway through a cdk deployment? CDK rolls back and figures out the issues. Crash during Pulimi? Unknown state but you can rerun it and usually get back up and running.