Here is one possible patch to fix this issue. The benchmark results in:
ReflectionUtils on post-patch branch-0.20: ~18.1sec
(still slower than 0.18.3 by about 2.5x but at least tolerable)
This is not the most elegant fix, but the ClassLoader inside Configuration makes it slightly difficult to do this at a different layer.
As for the importance of this - despite advice not to use ReflectionUtils in any hot path, there are cases when this happens. For example, MapWritable and GenericWritable do so for every deserialization. Outside libraries like Cascading also seem to not reuse objects in WritableDeserialization, and we have reports of some jobs spending nearly 100% CPU in Class.forName when profiled.
This patch is against branch-0.20 but should also work post-split after the file rename.