Java byte code is generally much smaller than equivalent machine code. If you use something like Multi-OS engine which statically compiles Java bytecode to native code for iOS it's fairly typical to see an order of magnitude difference in binary size.
This actually affects Android 5+ too (Multi-OS engine uses Android's AOT compiler) but since it happens on the device it doesn't affect download sizes.
It's true, Java bytecode was basically designed for small size. The goal was to transmit java apps quickly over the internet, a hope which mostly died off as JS took over, but which in some ways has been reborn with android (dalvik bytecode is somewhat different but is definitely small). The main tradeoff for the small size is a total lack of optimization until the JIT compilation stage.
But there's no way it's anything like a 10x difference. There's definitely something else going on here, like some quirk about how the app store is calculating the sizes of assets.
I'm talking about the binaries themselves as they are output from dex2oat. The 10x difference is I suspect a product of needing to compile parts of the standard library in addition to the app's code.
Many things that Java does with a single instruction take much more than that in the target architecture. For example, virtual calls (which are used almost everywhere in Java) take several instructions on x86 and ARM while only one in Java or Dalvik bytecode.
Its 174 MB installed with another 150 on Data which is a thing but I hardly use facebook once a day (just to see notifications not even the feed) which is quite big and no cleaner is going to delete the Data as it is not cache. Facebook app is a big one and I don't even know why.
LinkedIn: 20.36MB Facebook: 76.59MB Twitter: 25.71MB
That's about 1/8th the size of those apps on iOS. Those are just the first three apps in use article, I'm sure the rest are about the same.