Hi Anthony Vito - Thank you for your comments and I am very sorry to hear this problem has affected you as well.
After further analysis, I have determined the cause of the problem to be incomplete resource (i.e. GemFire/Geode cache instance) synchronization with Spring's SynchronizationManager as compared with other SD stores like Spring Data MongoDB, for instance.
I have a plan for addressing this and hope to have resolution on this issue soon.
In the meantime, you can register 1 or more Transaction callbacks directly with either Apache Geode or Pivotal GemFire using SDG's o.s.d.g.CacheFactoryBean or o.s.d.g.client.ClientCacheFactoryBean when creating a GemFire/Geode cache instance in a Spring context by calling the setTransactionListeners(:List) method and implement Apache Geode/Pivotal GemFire's o.a.g.cache.TransactionListener interface.
Once this issue is resolved, then you will no longer need to use the workaround and instead, you may rely on SpringTransaction Event Listener infrastructure.
After further investigation, it appears that this is not a bug and @TransactionalEventListener works as intended.
In order for the TransactionalEventListener to fire, an event must be published within a transaction (unless fallback is set to true, in which case it will fire the listener even when a transaction is not present); the event is not published automatically by the framework. When explicitly publishing an event from inside a method annotated with @Transactional, the listener fires as expected.