Stephan, I see you are using 5.4? In the earlier Mx5 releases there were several memory related issues that could occur. In a later Mx5 release (5.12 if I remember correctly) there have been a significant amount of improvements to the memory usage. I prefer the 5.13.1 version myself, which seems to be the best performing Mx5 release so far.
I do recall several issues being solved regarding the garbage collection in combination with scheduled events. I would recommend to start with an upgrade to 5.13.1 because there isn't too much that you can do to influence the cache cleanup.
By looking at the code from the example, that might work in some scenario's. However the way that this code is setup, in case an exception occurs or if you ever choose to do anything with custom error handling in the async microflow you will mess up the transactions in all the other async microflows.
The way this action is setup they share a session, context, cache, and even the transaction. That would mean that if any action changes something in the transaction, cache etc. it will impact the other transactions too.
The microflows you posted won't provide any issues with the Java action, but I would not recommend using that action with more complicated microflows (read: microflows that use custom error handling or are likely to give exceptions such as integrations).
So I hope that this solution will not make it into the community commons module.
To answer why this might solve your problem, the code uses the function session.retain and session.release those two functions tell the cache to keep the object until further notice. The release function instructs the cache that the object can be garbage collected.
The release function might trigger the cache to remove it proactively but I would not expect the release function to trigger the cleanup process though. In other words the release should only mark the object as applicable for removal, but should not proactively remove the object from cache (see also this new documentation page).