That's exactly the reason, to make sure bundles are not modified.
I don't think all bets are off because you can verify the signatures. Signatures of trusted sources can't be changed unless you know the private key to sign those. So either you unsign the bundle (and it will be known because the bundle won't return signatures) or you sign it with a different source which you'll know too.
The cpu consumption would only be there for signed bundles, and that's only about computing the checksum of the zip entry, which is quite fast, there's no real cryptography involved here, so I don't think that's a problem. Besides, that's a decision for the user to take.
The use case, to give a bit more background, is to give a trusted framework to a third party so that it will use it, but we need to ensure some stuff can't be modified by this third party. We don't trust the third party to not hack with our framework, so we need to secure it.
Imagine a payment application where you provide a service that will do some billing. You don't want the third party to start hacking the bundle in order to bypass the billing for example