Just wanted to share that so far - it seems really uncomfortable to move away from the legacy geo policy to updatable objects managed in security policy.
Using the legacy method, you manage the geo policy and the security rules policy separate, thus allowing you to order and tidy up the security policy anyway you want.
Using the updatable objects for geo policy as part of the security policy masses/breaks that logic/order.
For example, I am using inline layers like this:
Inside the WAN -> Internal layer, I have some rules like these:
So now I need to place the Geo blocking rules above this layer rule obviously and that's fine, but if I want to allow a domain object or other updatable object such as Azure, Office365, Amazon, etc` , I have no way of knowing if some of the addresses behind these objects are located in geo locations blocked by the Geo blocking rule above, so now I need to place these domain objects/updatable rules above the geo blocking rules and outside the WAN -> Internal layer which now breaks my logic/comfort.
Same goes for regular network objects with a public IP address, if the country behind the IP address (host object) is a geo blocked country, I can't place it inside my WAN -> Internal / Internal -> WAN inline layer, it would need to be placed in the Geo Exceptions section.
It is much more convenient when the geo policy is not part of the main security rule base, since it allows you to create exceptions which are not dependent on the security rules location.
Just felt like sharing this feedback.