With regards to "understanding it," I mean knowing what it's doing under the hood. It's all well and good to know that you can install something by doing "helm install," but you should really know what helm install actually does.
With regards to "when it's useful," I mean when you have a very complex system that needs a high level of abstraction to make manageable.
With regards to "when it's not [useful]," I mean various scenarios. For example, when you really only need a single pod running with no configuration and no ingress, Helm is not only overkill, but also a negative, as it abstracts without adding any value.
The fact you add complex logic in the chart makes deployment logic problematic when debugging complex workflows because team1 instilled all the logic in the CI while team2 in the helm chart(!) and team3 50-50.
I prefer using bash + gnu utils (envsubst & see) and kustomize than playing around with a template language running on top of another … the funny part was that we run all this thing via Jenkins & bash. I recall having to use an inordinate number of escapes in some cases… anyway.
> when it's not: 100% of the time.
I see a lot of things that has to be solved on your own even when using Helm. I find their templates repulsive. But "avoid helm" is not an advise, really. How do you suggest to structure, version, deploy, encapsulate with important metadata your deployment descriptions? How do you package it? Is there anything else that integrate with larger tools like Rancher so well?