[G Pad 8.3 Android Development] okibi:
Well, I'm glad we agree on deodexing is commonly used to make it easier to apply themes and mods. I'm aware it's not required, but many more modders would prefer deodex. Also, if they are going to mod services or framework, we should go ahead and deodex the entire ROM.

As for the second part, I'm not sure what you're getting at. For starters, that setup has nothing to do with the issue of the "wipe method". That's an unrelated issue. As for how odex and dex files are treated differently for apps in regards to dalvik, that is a brief high-level view of how it works. I went ahead and did a little googling and grabbed some top links:

From: http://www.ddsystems.com.au/other/android-2/android/

"Dalvik-cache

When your phone starts up, the Dalvik Virtual Machine looks at all your apps and frameworks, and creates a tree of dependencies which is stored in the dalvik-cache. This allows applications to run in an optimised state (and explains why your phone takes longer to boot up after applying a new rom, it’s rebuilding the cache.)"

and

"Zipalign

Zipalign is an archive alignment tool in the Android SDK that provides important optimization to Android application (.apk) files. The purpose is to ensure that all uncompressed data starts with a particular alignment relative to the start of the file. The benefit is a reduction in the amount of RAM consumed when running the application."

and

"ODEX – DEODEX

.DEX files are compiled-code versions of APKs that are created on-the-fly by Android, namely by Dalvik VM, hence the name: *D*alvik *EX*exutable. ODEX are Optimized DEX files that are created ahead of time for System apps with the DexOpt SDK tool. The benefit is that these apps start up faster because of the optimization. The drawback is that the APK that’s been ODEX’ed will not work without the corresponding .odex file present, which almost doubles the size of the app. Deodexing means you convert it back to a .dex file and put it back inside the apk. This allows the programmer to easily replace files (not having to worry about odexes), but the main point was to deodex services.jar so that programmers can change all text to different colors (such as the clock color to white) and to deodex services.jar, you need to deodex everything."

You can even look through some of the documentation on dalvik and how it handles optimizations. Here's some of Google's top results:

http://milk.com/kodebase/dalvik-docs-mirror/docs/embedded-vm-control.html

and

https://android.googlesource.com/platform/dalvik.git/+/master^1/docs/dexopt.html

Point being, clearly odex trumps dex in regards to performance, that's the entire purpose of them. What I'm saying is that with the right configurations, you can allow the use of deodexed files within a ROM (that modders I've talked to prefer) while still getting fairly close to the same results as using odex files themselves. I've been building Android ROMs for 5 years and I've played around a lot with these settings and have done performance benchmarks. I wouldn't try to sell "DEODEXED" as a huge plus for the ROM itself, but more for what you can expect in the long run by modders. It has almost always attracted more in my experience.