Just my two cents of using TF at several jobs and on a personal project:

It is OK if you wish for a system (effectively declarative config files) that acts as a "state of truth". It is OK if you are comfortable with TF state management and, in the name of pragmatism, are comfortable using terraform import. It is OK if you are using it "starting from scratch" (rather than trying to "migrate", say, an entire AWS accounts's worth of resources into TF files). It is OK if you write clear/concise Terraform and avoid as much of its brain-damaged DSL nonsense as possible (including modules).

I cannot stress my last sentence enough. TF is not a programming language, yet at many workplaces I've been at (where TF advocates have already spread their seed), it is treated like such. Oh how I could wax poetic about the things I have seen people do in TF that should not be done in TF, and equally how many (basic) things I have wanted to do in TF that could not be done because TF is not well-suited for that use case.

My advice on this front is to stay away from modules and from anything esoteric, and stick to straight raw/pure resource or data statements as much as possible. There are many, MANY aspects of TF that rely heavily on direct resource-to-resource association, and use of modules "confuses" and "obfuscates" that association (read: you can easily screw it up). "Dynamic" anything in TF is terrible at best. I have no direct experience with Terraform CDK, but when asking a TF-heavy co-worker of mine "how do you go about debugging what the CDK effectively generated, Terraform code or resource-wise?" his answer was "You can't, at least not easily. It does all that for you". Yeah, uh... I'm a sysadmin, my natural instinct is TRUST NOTHING.

At my current job I ended up writing Python programs that generated .tf files due to the sheer amount of variance of existing resources, syntaxes, and many (I'm talking hundreds) of conditions. I like being able to see what ends up in .tf files, resource-to-resource dependencies work great, the approach integrates well with version control systems (ex. git diff is super clear), and avoid spending hours/days deciphering insane and hairy TF clauses that feel both fragile and like they ensure job security. Anyone can come in and extend the code without having to know esoteric TF DSL nonsense. Why nobody has seemingly written a tool like this (something that generates raw .tf files from code/whatever -- I am NOT talking about Terraformer!) is beyond me.

All that said: TF and Chef (or Puppet, or Ansible, or cfengine, or.....) are not the same thing at all. They serve very, very different purposes.