Bottom line: I'd opt for self-contained unless/until you have convincing proof that putting the frameworks in /Library/Frameworks/ will offer a noticeable improvement for your particular scenario. Check the impact of doing it both ways, but I prefer to group the frameworks with the app to begin with.
The dynamic linker (dyld) is pretty smart about loading frameworks and reusing what has already been loaded in most cases. If there are several apps in disparate locations using a framework, it is definitely preferred to install it to /Library/Frameworks/. However, since it seems that all the "apps" you're referring to are within your .app bundle, it wouldn't seem there's much benefit to this approach, since they'll all be linked to the same path, which dyld should pick up on. (Not only is a user required to have admin permissions to modify /Library, but the install process instantly becomes more complex.) See the last part of my answer to a related SO question for ideas about analyzing launch performance of executables, including examining dyld activity.
Another consideration is the degree of control you have over framework versioning when they are stored within your app bundle. If you purposefully "publish" a framework by putting it in a canonical public location, you must be prepared to accept the consequences of others possibly choosing to link against it. However, if a framework is only distributed inside your app bundle, any developer who chooses to link against it anyway has nobody to blame but themselves. :-)