I am afraid this PR has currently two many open questions / issues. Instead of commenting on individual lines, I would like to outline them here as basis for discussion.

• I am not convinced that we should add hostpath as a CSI option at all. I am quite sure we can make it work, so from experimentation point of view it won't bring any new information. Since it's not something we could use in production, I would only add it if there is a strong need to test storage workloads before the "real" kubevirt CSI driver is ready. So far, I am not aware of such a need.
• If we decide to add hostpath CSI, I would strongly prefer to have this configurable per shoot, and introduce a general mechanism to add other CSI drivers (e.g. Ceph FS, etc.) configurable per shoot. E.g. on some shoots we want no CSI at all, on others only hostpath, and on others both hostpath and ceph.
• The charts in seed-controlplane and shoots-system-components are quite different from charts for other cloud providers, see e.g. https://github.com/gardener/gardener-extension-provider-gcp/tree/master/charts/internal/seed-controlplane/charts/csi-driver-controller and https://github.com/gardener/gardener-extension-provider-gcp/tree/master/charts/internal/shoot-system-components/charts/csi-driver-node. There is no reason not to stick to familiar ways here - csi-hostpath is just yet another CSI driver and all the other aspects should still be valid. The current charts are also incomplete. In short, they would have to be reworked entirely before they could be accepted.
• Code to properly configure CSI chart values in the controlplane controller is also missing, see e.g. https://github.com/gardener/gardener-extension-provider-gcp/blob/c940f39c4329a904a115c795d534d2312e562c0a/pkg/controller/controlplane/valuesprovider.go#L437-L473.
• For CSI to work, changes to the controlplane webhook are needed as well, see all the CSI-related stuff e.g. in https://github.com/gardener/gardener-extension-provider-gcp/blob/master/pkg/webhook/controlplane/ensurer.go.

For all this reasons, I would not reject this change, but I would ask not to continue working on it until we have decided that we definitely needed, and if this is the case, also discussed the aspects above to ensure that it's added in a way that is both configurable and consistent with other provider extensions.