Upon review I think we should be defaulting to the comprehensive listener cleanup strategy (old one) and only enabling the new (approx. 30% faster) approach if the config. parameter is enabled.
The rationale for this is that there is a real risk that some of our custom components (gmap, inputRichText) or the application itself could add JS listeners that are not covered by the faster static listener cleanup approach, resulting in a browser memory leak.
For customers with existing apps. this will be interpreted as a bug in the EE release. I would rather have things slightly slower and not crashing from memory leaks out of the box, with the option of them turning on "com.icesoft.faces.optimizedJSListenerCleanup" mode prior to them completing extension application testing (which will uncover any issues), than have them attempt to switch and run into problems that appear to be mysterious browser memory leaks that were never present previously.
Note the suggested name change for the config. param above also.