It sounds like the real issue might be you are expecting libraries to use additional localizations beyond those supported by the main application bundle. If so, setting CFBundleAllowMixedLocalizations to YES in the application’s Info.plist is the proper solution.
To explain the nature of the workaround you found:
The localizations supported by a particular bundle are the union of the lproj folders, the CFBundleLocalizations you found, and CFBundleDevelopmentRegion. (The relevant bundle in your case is the main bundle of the top‐level application.) If a module includes no localized resource files, then Xcode will not bother to create an empty lproj. Empty directories are somewhat brittle anyway. That is likely why you needed to add to CFBundleLocalizations even though you had already told Xcode which localizations you cared about.
But none of that matters if you turn on CFBundleAllowMixedLocalizations—which ought to have been the default in my opinion. Then the main bundle does not restrain other bundles’ selection of localizations.