My practical experience has been that, in a microservices architecture implemented using Helm, each individual service should have its own Helm chart.

The real problem is that Helm doesn't deal well with recursive dependencies. A typical architectural statement is that each service has its own independent storage and no service "borrows" another's storage. If charts A and B both say in their requirements.yaml that they need some database as a dependency, and your "wrapper" chart W depends on A and B, then Helm's resolver will instantiate a single database dependency chart and use it for both components.

This style is also somewhat easier to deploy. If you take the Docker image tag as a parameter to the chart, then you can deploy each chart/service completely independently of everything else. With one "wrapper" chart you need to be continuously redeploying that chart and coordinating changes to its specific values. (The reverse of that is that it's a little trickier to know what specific versions of the entire system are deployed all in one place.)