While I agree generally, this isn't helpful for someone trying to expand their knowledge. Helm is a popular tool, and it's important to understand it, when it's useful, and when it's not.
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.
To my experience helm is great at some things but the fact that does too many things leads to engineers shooting their foot and then you have two problems: K8s and helm problems to solve ;-)
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.
