If anything it sounds like it would be faster because there is less byte code which needs to be compiled.
Most likely the problem is the Facebook app has a lot of bytecode. That's probably why the wrote redex in the first place, so they would have less bytecode in their final APK.
There was a post on HN [0] a few years back about the Dalvik patch that Facebook used for their Android app, due to the large number of methods [1] the app had. This was causing issues on the older Gingerbread devices, so their solution was to modify the internals of the Dalvik VM while it was running their code to increase the buffer size.
Their ios app has over 18000 classes (https://www.reddit.com/r/programming/comments/3h52yk/someone...), so I can easily believe the android app is similarly bloated as well. (To be fair, most of the 18K classes seem to be auto generated, but that still doesn't lessen the compiler's burden.)
I heard there are something like 400 mobile developers working on the FB apps. I don't know there's any way to keep a team that size from producing bloat with every revision.
That seems like a useful engineering problem for Facebook to try to solve, rather than this bullshit rocket science optimization stuff that adds yet more complexity for only incremental gains.
My take: If you can't write it fast enough in Java, it is probably not a good mobile app candidate in the first place. The Dalvik optimizer and the JIT yield a regularly reasonable experience for me.
