vcenter-event-broker-appliance VS kyma

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/

Although I had the project on my radar, I never took a closer look at it. However, now it was the time to give it a spin ... or try. All I needed was a Kubernetes environment. As I am working in the SAP space the choice of Kubernetes is kind of predefined, namely Kyma in its managed version on the SAP Business Technology Platform.

News from the SAP side: the clear focus is here SAP Business Technology Platform especially Kyma

I could only find https://github.com/kyma-project/kyma as something close to being real-world. But my google fu is failing here. Any help would be appreciated :)

I am using Kyma as opinionated stack on top of Kubernetes (to be precise on a Gardener cluster) for this exercise. The setup should be similar for vanilla stacks, but the API gateway must be adjusted accordingly depending on what you use.

So you can install Kyma 1.x without own domain, but you have no access to the Kyma console UI. An issue is open for this (https://github.com/kyma-project/kyma/issues/11924) and according to the Kyma slack channel the situation will improve with the upcoming release of Kyma 2.x, but until then you must provide an own domain to get access to the Kyma console UI. From my point of view this lifts the entry barrier of trying out open-source Kyma, but currently this is the way.