I gave decompiling/data mining a shot earlier. Turns out, the devs ended up running the assembly through Obfuscator Pro, so the class names are all jumbled and the strings are all base64-encoded with the first character being xor'd against the results of a lookup table. Blech. I gave up after 15 minutes, but I still managed to get more fun out of that than I did playing the actual game, and made an interesting/horrifying discovery in the process.
I stumbled into the creature code at one point, and after going through it I kinda suspect that the widespread string obfuscation is one of the reasons that the game performs as "smoothly" as it does. Every time it looks up a string the runtime has to make two function calls—one to call into the decoder's wrapper library and one to jump into the actual decoding method with the appropriate magic number. The base class for all of the enemies in the game has a standard Unity Update() function, which performs no fewer than 13 string lookups (some creature implementations have even more). That means that the game is doing at least 26 function calls, per enemy, per frame. At 60fps, that's 1560 calls per second—again, per enemy—and given that Unity reportedly doesn't do much in the way sort of runtime inlining…yeah, that's gonna add up fast.
Just to attach some number to how bad this can get, on my system it took 2.5-3.2ms to perform 15600 of these decoding calls (1560 calls across ten enemies) using LINQPad 5, regardless of optimization settings. Considering it's 16.67ms per frame at 60fps, there's a pretty significant amount of time every frame dedicated to doing, well, nothing of value. Also, that's only considering enemies. I'm sure there's plenty of other objects that do this as well.
So, yeah, if 0.4.x (which wasn't obfuscated) ran fine and 0.5.x chugs, that's probably a big reason why.