At least for me, there is a big difference between naming things at home and naming things for work.
Work “pet” machines get systematic names based on function, location, ownership and/or serial/asset numbers. There aren’t very many of them these days. If they are “cattle” then they get random names, and their build is ephemeral. If they go wrong or need an upgrade, they get rebuilt and their replacement build gets a new random name. Whether they are pets or cattle, the hostnames are secondary to tags and other metadata, and in most cases the tags are used to identify the machines in the first instance, because tags are far more flexible and descriptive than a hostname.
At home, where the number of machines is limited, I know all of them like the back of my hand, and it’s mostly just me touching them, whimsical names are where it’s at.
Pulumi code ends up looking like a DSL anyway with all the stuff you end up using from the top-level pulumi package to do anything vaguely complicated.
Only now, compared with Terraform, you need to worry about resource ordering and program flow, because when you have a dependency between resources, the resource object you depend on has to be instantiated (within the program flow, I mean - Pulumi handles calculating the ordering of actual cloud resource creation) before the dependent resource. This gets old really quickly if you’re iterating on a module that creates more than a few interdependent resources. So much cut, paste, reorder. FWIW CDK has the same issue, and for the same reason - because it’s using a general-purpose programming language to model a domain which it doesn’t fit all that well.
I like Pulumi and it’s got a lot going for it, especially if you have complex infrastructure requirements. You get a bunch of little quality of life enhancements that I wish Terraform would adopt, like cloud state management by default, and a built-in mechanism for managing secrets in a sane way. Python/TypeScript etc. modules are much more flexible than Terraform modules, and really help with building large chunks of reusable infrastructure. The extra programmability can be useful, though you need to be extra-careful of side-effects. You get more power, but you also get some extra work.
But for most people deploying a bit - or even quite a lot - of cloud infrastructure, Terraform is honestly just easier. It’s usually some fairly simple declarative config with some values passed from one resource to another, and a small amount of variation that might require some limited programmability. Which is exactly what Terraform targets with HCL. It’s clear to me that Pulumi sees this too, since they introduced the YAML syntax later on. But IMO HCL > YAML for declarative config.