A) Thank you for not only telling me, but providing a link to this forum. Most users simply talk to each other, and do not report issues.
B) However, this thread is not providing any concrete numbers, or any indication of testing methodology. Meanwhile, there is disagreement among users as to what version is even causing the problem.
Let me be clear about this: MobileSubstrate doesn't actually /do/ anything. If you install just it, and you let your phone then sit there not doing anything, it will /never/ use any CPU, ever. When a program starts up it is injected into its process space, it iterates a folder to see if it should inject anything else, and that's it: if there is nothing in that folder then its involvement in that process is entirely done.
This regime is so thoroughly enforced that the engine it comes with for letting extensions modify code is actually bundled separately, and will not end up in any processes unless one of the extensions actually needs it and requests it.
It's even better than this, though: MobileSubstrate only even loaded anything at all in user space on the primary CPU. Put differently, it only affects normal boring applications. This entire CPU is simply put to sleep when the phone is on standby, and is only woken up occasionally for timers, like an alarm or a calendar event.
I have just now verified that this is the behavior I'm seeing on my device: the entire night my phone was asleep, except at 3am when it woke up to do this "provisioning profile janitor" task that Apple apparently thinks is important enough to do every day at 3am, and which I had never heard of before and am now incredibly curious about the purpose of ;P.
Therefore, it is very difficult to understand how MobileSubstrate could possibly cause whatever issue you feel you are experiencing.
Meanwhile, things people really care about, things like battery life, memory usage, and signal strength, are very difficult to measure. The reason for this is that devices that are this complex use these resources in difficult ways, and they aren't things that you can directly just count.
Like, you can't use the battery percentage indicator to do this, as there is a /large/ amount of complex math that is going on just to pretend that it has any clue how much battery you have.
Example: if you leave it charging while it is at 100%, it typically will keep charging for quite a while, as it doesn't really know it is charged fully, and will continue to trickle charge as it thinks is safe. Then, when it starts discharging, its knowledge of how charged the battery /may/ have updated, allowing it to start decreasing the battery life. However, it also may have not: it depends on how many times it has seen itself in this state.
Then there are issues that simply rebooting the phone is going to cause major changes for a lot of users. As the device is used for a while, memory in processes starts getting fragmented, which leads it to page more and more. You can restart SpringBoard, which helps some, but you really need to reboot to totally fix the problem.
For most users, the only time they reboot is when they upgrade or downgrade MobileSubstrate. Therefore, users who believe "man, my battery performance really sucks" go and do something, and then are like "wow, this helped a lot, thanks!". Unless you switch back and forth multiple times, performing a careful test each time, the data is therefore totally worthless.
Meanwhile, I happen to know that planetbeing has been doing extensive tests regarding the battery usage of ultrasn0w, as he became paranoid that he was doing something weird with the debug serial port after receiving a number of comments like this. As far as I understand, these tests have shown "no drain" (whether you are using ultrasn0w 1.0 or 1.1, btw), and as ultrasn0w uses MobileSubstrate, I can infer.
Finally, there are also comments here that make it sound like jailbreaking itself is an expected battery drain, and that downgrading MobileSubstrate is bringing users "almost" back to where they had been before jailbreaking. Jailbreaking literally changes a few bytes in the kernel, and what it does is actually /bypasses/ code; if anything, if we could measure battery life effectively, what we'd find is that jailbroken phones get infinitesimally /better/ battery life than non-jailbroken phones.
So, please: if you would like to report a battery drain issue in something, I really need you to provide your testing protocol, so we can actually analyze it and determine if it is a true cause of concern or not. When I did similar things for people claiming memory usage issues with WinterBoard, I found that there were serious issues in the "common sense" way people were trying to measure that, and was able to elucidate some the issues.
