Please note that the specific corruption issue that you reference was not and is not the only reason to avoid the use of G1 with Elasticsearch. It's just that the corruption issue was a clear reason to never even consider using G1 with Elasticsearch. Any additional discussion until that point was resolved was moot. Issues remain though:
- the performance tax going from CMS to G1 is quite significant due to the use of more expensive write barriers; this has a substantial impact on throughput
- G1 has a larger footprint due its remembered sets and collection set
Here is one example of the impact G1 GC had on a cluster: Indexing performance degrading over time
CMS is well-understood, stable and very mature at this point. Switching to G1 GC carries a heavy cost with no apparent benefits.
You are right to point out that G1 will be the default in JDK 9, but that does not mean that it's ready for primetime. In fact, there is plenty of concern in the community that this is not the case.