vcenter-event-broker-appliance VS gardener

Your conclusion is correct, an Alarm can not be trigged once the vSphere Object has been destroyed as the Alarm is mapped to that object. The Event is there and one easy and recommended solution is to leverage the VMware Event Broker Appliance (VEBA) which makes building Event-Driven Automation super easy as you only have to subscribe to Event you want and then have it run the code you desire. Here's an example https://github.com/vmware-samples/vcenter-event-broker-appliance/tree/85494d3d09d66397358b3236778a80db8ad46554/examples/knative/powershell/kn-ps-vsphere-inv-slack that you can refer to and to learn more about VEBA check out https://vmweventbroker.io/

Now, if you want to dig further on how cloud providers operate, like I said, most are actually using Kubernetes to automate the client control plane management. There is a cloud-neutral project for this out there called Gardener, they have a few architecture documents which explain the concept a bit further. In their garden metaphor, the seed cluster hosts the client control planes, and the shoot clusters are the client clusters (which are only made of worker nodes, no control-plane node). Another more specialized implementation is Kubernikus for OpenStack.

Gardener: https://github.com/gardener/gardener RH HyperShift: https://github.com/openshift/hypershift

Gardener does exactly that. One global cluster manages smaller per-region/cloud provider management clusters and those will contain the control planes of your workload clusters. This way you can have like 10 000 clusters and not deal with multi-tenant issues. One workload = 1 cluster.

We had cluster of cluster style management managing 100s of cluster. Check out https://github.com/gardener/gardener for an inspiration

How does this compare against simply using Gardener [0]?

[0] https://github.com/gardener/gardener