I don't find HCL easier to read or write than yaml. I think it is just what you are familiar with. HCL is also only used for one purpose with yaml is used for many things.

Using helmfile (yet another layer of abstraction on top of helm) lets you get diffs between current and new releases. And it’s all templated so could be dynamic.

At a previous employer they were using helmfile. I don't remember what exactly I needed to do but I needed a value to be templated by helm _after_ helmfile had done its work (iirc) and ended up having to write along the lines of "{{ `{{` }} .Values.something {{ `}}` }}" but actually had more levels of nesting which required use of `printf` iirc and I don't remember how I actually solved it.

My point is though that using string templating for YAML creation is IMO always a bad idea and using helm for anything more complicated than the most basic application always makes me sad in the end. helmfile adds another templating layer and my limited exposure to it made me really dislike it.

edit: I remember now that this was for rendering config for vector, which itself has templating support with the famous `{{ .key }}` syntax. So not entirely helmfile's fault, but I still stick to my point as I needed to get through 3 levels of templating.

Yes, that sucks.

> Using helmfile (yet another layer of abstraction on top of helm) lets you get diffs between current and new releases

Of the config, not of reality. What if someone made a change in the meantime? Or something is in a half or fully broken state?

> And it’s all templated so could be dynamic.

Not dynamic based on things external to that Helm deployment. You can't have two Helm charts referencing each other dynamically, or anything else external for that matter.