For my personal cluster, I have a private Git repository filled with various singleton manifests that help me bootstrap various different things. Most "standard" installs (nginx-ingress, cert-manager, istio, etc) provide their own single manifests as well.
I feel that introducing layers of abstraction on top of that is generally unnecessary, but particularly because it doesn't really help you understand how K8s works.
Expect I'll be creating a chart for our fairly complex application stack very soon.
True at a certain level of abstraction, and like another reply says at heart helm is "just" a templating system. However you'd be doing a lot of kubectl apply-ing to replicate the functionality and configuration options of, say, the stable prometheus or nginx-ingress charts. At its best helm really is the package manager its designers aspired for it to be, and if the work is done to create good charts you can get a lot done with a 'helm upgrade --install'. That said, although we use it extensively for infrastructure-level pieces like the examples above, we find it too complicated and indirect for deploying our own services. For that we use kustomize (which is in kubectl now) to apply yaml patches and kubectl to deploy the manifests.