By default, the application will use the best of its own matches for the user’s localization. Then it will attempt to use that same localization from all of its dependency packages.
So a brand new application from the template with only en resources of its own will also only use en from your package. (Sometimes that is what the client wants.)
If instead the client wants to use de, es, fr or it from your package even in an application that only has en resources of its own, then that client should set CFBundleAllowMixedLocalizations.
This strategy may cause mayhem if individually localized strings are being interpolated into each other across module boundaries. You can wind up with things like “Today is Montag, le 1er décembre.” That caveat is probably why Apple refrained from making it the default. But as long as you steer clear of that, most users will be glad to have the menu bar, file system errors and the like in their own language even though a game script may only be in English. I always use it.
It sounds like that developer finds the CFBundleAllowMixedLocalizations style better too, although it is entirely up to that developer and not something you can control as a package vendor.
That puzzles me too if it really did behave differently before. But until I see a reproducible case, I suspect that the client must have done something else different without realizing it. For example, when they remember it pulling de from your package, it might have been a project that also had de resources of its own, and now they are looking at a different, fresh project that doesn’t have any de resources yet. Or maybe they set en in a scheme for a testing run and what they observe is actually responding to a launch argument override instead of resolving like it would in a real install.
Ultimately, if you are using Foundation’s NSLocalizedString, then it is macOS that is selecting the resources for each bundle according to the various Info.plist files involved. Except what you see in the property lists, nothing is controlled by Xcode or compiled into the application. So the Xcode version cannot make any difference. If something did change, it must have happened with an operating system update instead. (But each style is used by some of the applications I work with every day and my language settings are wild enough that the difference is immediately obvious. With daily evidence of both styles behaving consistently over the course of years, the idea that something changed without my noticing seems fishy to me.)