Thanks!
I think Ambassador has better self-service CRs that function together well without needing to define explicit dependencies. An example is TLSContexts and Mappings. As long as you have a host value in your mapping which matches exactly the host value of a TLSContext, that cert is used. With Gloo, it's structured differently altogether, but they have no separate resource for tls/ssl. It's defined in the VirtualService itself, so strongly coupled to the routes. Route delegation (in newer gloo) helps with this a lot!
I believe the gloo GitHub has an open issue for making ssl config its own CR, which should help.
One other thing is Ambassador (starting in 1.0) allows Mappings to be created that refer to Kubernetes Services by name, using the Namespace the Mapping is created in to find that Service.
This is incredibly helpful when you have the same services but in different Namespaces (like with multi-tenant clusters), because the same set of Mapping YAML can be applied in each Namespace without having to first generate them from templates. It depends on how you deploy.
If you're not planning to have a huge cluster with lots of dynamically added routes, and don't already have complex deploy logic, I say it's fine to keep using Ambassador. Although due to the complexity of switching ingress controllers, standardizing on one is worth it IMO.
About the Edge stack, I did try to use it, but I was unable to successfully get it to deploy in a fresh cluster. This was literally the week of them launching it, so stuff was chaotic. I also had modifications to the codebase that were required for me to use it effectively, and Edge stack is a special container that has things baked into it, so I couldn't simply change the Deployment YAML to use my container image based on the OSS version :(