The same argument applies to the use of "Debug" and "Release" configurations though.
These are merely arbitrary labels subject to change by the user. There's no guarantee someone will have a "Debug" or a "Release" configuration nor is there any objective reason why they should be required to have one.
At least half the projects I've worked on in my career changed these to other things, such as "Dev," "Staging," and "Distro" etc. It's also common for a specific team within the org with their own CI to use special configs that only they and their CI use, to insulate the production CI pipeline from whatever they're doing.
In our case we're simply using Packages to create modules to add new modules to our app (in the past we always used Frameworks but we are hoping to use Swift packages now since it's so much lighter-weight than creating a whole framework, and nobody likes dealing with merge conflicts in Xcode project files when multiple devs are moving files around).
The inability to specify the name of our existing build configurations is really crippling for using Swift packages within our app. I don't understand why simply letting the user specify whatever configuration name they want would be a big deal. We use a monorepo so there's no sense in which "package management" even comes into play for us, at least not for our app's own modules.
If you're making a Swift Package for distribution, and the concern is that people won't want to add configurations with the names specified by the package, then I agree with you, we shouldn't use "the name of which configuration is active" as a criteria in the first place.
What would be better is something like "Package Features" idea that Daniel mentioned in My SwiftPM wishlist (aka proposal proposals),
100% agreed here.
Like maybe a package could define its own build-time flags like "MyPackageName_Testing", and the BuildConfigurationCondition would be contingent on this flag being set.