This is not to prevent trojans from coming from the App Store, it is to decrease the attack area of apps if exploits are found through them. For example suppose an app registers an URI handle, but does not properly sanitize the data before processing it leading to an arbitrary code exploit. It would still have to bypass the sandbox to further infect the system. Yes, pretty much all malware software is based on trojans. But that doesn't mean that ignoring other risks is a good thing.
The biggest problems with sandboxing is making sure that rules are tight enough but no tighter. Most of the developer complaints I've seen are either the "sandboxing is hard, I don't want to worry about enumerating what my app will do so that everything else can be blocked" or the "sandboxing is fine in principle, but without the ability to mark ( plugins / full filesystem access / ) as allowed my app will ( have reduced functionality / be unable to work )." The later issues are the ones I think that have merit. I can understand Apple being extremely tight with the original permissions because it's easier to loosen up rather than tighten, but it is going to limit what apps from the App Store can do. Hopefully they will be using some of the extra time from moving the sandbox deadline that was originally this month to March, to improve selection of the sandbox criteria to better meet the needs of some of the developers that are unable to work with the options currently provided.
The one thing I like about Apple's sandboxing over some other approaches is that it isn't noisy to the end users. People like most of us on this forum might care, but the average user sees a dialog that such an such app is requesting permissions to do . and there eyes glaze over and they either just press accept to get to the program or start panicking needless and become more susceptible to fake antivirus software claims.