The savings in space on the filesystem varies depending on the number of apps and whether the ROM is "Properly" odexed or not. If it's not properly odexed, the filesystem will end up even larger than a DeOdexed filesystem.
In a DeOdexed ROM, for every APK or JAR file, there is a classes.dex file within that APK/JAR archive. From this classes.dex file, the Dalvik Virtual Machine decompiles and stores an extracted/optimized classes.dex file known as the "dalvik-cache". So, in short, you end up with 2 dex files for every apk and jar package. 1 that is zipped into the apk/jar, and 1 that is extracted into the dalvik-cache directory.
In an Odexed ROM, for every APK or JAR file, there is a .odex file within the same folder that the APK/JAR is located. However the "classes.dex" file we spoke of earlier is no longer found inside a "properly" odexed apk or jar package. Where did it go? Well, it is the .odex file. It has simply just been pre-extracted, decompiled, and optimized for the system to use. And all without having to store it in the dalvik-cache directory. So, in short, you only end up with a single dex file (in this case, .odex) for each apk/jar package.
So, that's where you see the filesystem space savings.
The initial ROM size of an Odexed ROM is larger than a DeOdexed ROM (because the classes.dex files are zipped/compressed within the apk/jar package, whereas .odex files are not zipped/compressed).
But, after a DeOdexed ROM has initially booted up (I'm sure you've seen the message upon boot-up after clearing dalvik-cache that says "Android is upgrading x of xxx files), the resulting filesystem size is quite a bit larger since it now essentially has 2 copies of each classes.dex file from each apk/jar package (one compressed, the other decompressed).
Now, I said something about a "properly" odexed ROM. There are instances where a person will Odex their ROM, but won't pull the classes.dex file out of the apk/jar package after it's been odexed. This results in each apk/jar file potentially having 3 copies of the classes.dex file. 1 located within the apk/jar package (compressed), 1 located in the same folder as the apk/jar package (decompressed .odex file), and 1 in the dalvik-cache directory (again, decompressed as a classes.dex file).
Whew. That was a long explanation, but hopefully it gets the point across.
One thing I'm curious about is if ART will work with a "properly" Odexed filesystem. The reason I question it is because LG's filesystem would NOT be considered "properly" odexed since each apk/jar package has not only a .odex file, but also has a classes.dex file located within the package. So I have to wonder if ART uses the classes.dex file much like the Dalvik Virtual Machine, and that it won't convert a .odex file to an .oat file.