Thank you for investigating the issue in detail.
I checked, and your analysis is correct:
The specfile parser that checks for used sources does not consider those macros at all.
Adding them in is easy.
Your proposed default action of downloading everything is also sensible.

I wrote pull request #678.
I would still like to test it more.
Or, if you have the time to test it and report the results to the pull request, I would be grateful.

Testing with a package that has a rhel==8 conditionalized source.

[python3.11-pip (c8s)]$ centpkg sources 
Downloading pip-22.3.1.tar.gz
######################################################################## 100.0%
Downloading pip-22.3.1-man.tar.gz
######################################################################## 100.0%

And:

[python3.11-pip (c8s)]$ centpkg --release c9s sources 
Downloading pip-22.3.1.tar.gz
######################################################################## 100.0%
Not downloading unused pip-22.3.1-man.tar.gz

And:

Parsing specfile for used sources failed: Branchname: batman is not valid
Falling back to downloading all sources.
Downloading pip-22.3.1.tar.gz
######################################################################## 100.0%
Downloading pip-22.3.1-man.tar.gz
######################################################################## 100.0%

Same behavior with actual branches.

[python3.11-pip (c10s)]$ centpkg sources 
Downloading pip-22.3.1.tar.gz
######################################################################## 100.0%
Not downloading unused pip-22.3.1-man.tar.gz

Or

[python3.11-pip (batman)]$ centpkg sources 
Parsing specfile for used sources failed: Branchname: batman is not valid
Falling back to downloading all sources.
Downloading pip-22.3.1.tar.gz
######################################################################## 100.0%
Downloading pip-22.3.1-man.tar.gz
######################################################################## 100.0%

The message is quite hard to understand here, but it does what it should do.

Can the message be amended? E.g.

Parsing specfile for used sources failed: Cannot determine release information from branch/--release "batman".
Falling back to downloading all sources.

Thank you for testing.

The important part of the error message comes from centpkg.
How this works is that there is shared code in rpkg,
and fedpkg, centpkg etc. overloading things as needed.
One of the main overload points is load_rpmdefines,
where the mapping from project's branch names to rpm defines happens.

For instance, with fedpkg I get a better error message:

$ LANG=C.UTF-8 fedpkg sources
Parsing specfile for used sources failed: Could not find the release/dist from branch name batman
Please specify with --release
Falling back to downloading all sources.
Not downloading already downloaded mercenary-0.4.0.gem
[otto@ottovain rubygem-mercenary]$ LANG=C.UTF-8 centpkg sources
Not downloading already downloaded mercenary-0.4.0.gem

So it seems that to improve the error message, a centpkg issue/pull request should be filed.
I will leave that to people who are involved with that project.
The string that needs to change is written here.

But that ain't much better in fedpkg, is it?

$ fedpkg --release batnam sources
Parsing specfile for used sources failed: Could not find the release/dist from branch name batnam
Please specify with --release
Falling back...

It tells the user to use --release even went hey did.

IMHO we should override such messages here, only for this use case, and provide a fine-grained warning that will not confuse the users.

But that ain't much better in fedpkg, is it?

$ fedpkg --release batman sources
Parsing specfile for used sources failed: Could not find the release/dist from branch name batman
Please specify with --release
Falling back...

It tells the user to use --release even when they did.

IMHO we should override such messages here, only for this use case, and provide a fine-grained warning that will not confuse the users.

You are right, even the fedpkg variant has a weakness.
I created fedpkg#518 to improve on that.

I disagree with handling this as a special case for two reasons:

1. In the rpkg context, there is no way to know what went wrong with the overloaded load_rpmdefines.
   It is a good guess that either --release was set incorrectly or the Git branch is custom,
   but in reality, the overriding function may be doing anything, thus be failing for any reason.
   So the only way to get reliable printout for the user is to rely on the resulting exception,
   and fix the source of that exception if it contains a bad error message.

2. Many commands needs to know the release, thus load_rpmdefines is very commonly called.
   If the bad errors are fixed here by special casing, all the other commands will remain broken.
   it is better to fix the problem at the source, and get the benefits for all commands.

Commit 8667d537 fixes this issue

Updated and merged rpkg part; fedpkg is pending review.

The pull request has been merged, but it is somewhat different than @churchyard suggested,
so I would like to double check.
Even if you did not get all your wishes in,
is the fix still an acceptable solution for the issue you are/were facing?

I think so, thanks.

Commit 6a381fd9 fixes this issue