Is it necessary to include all these env_vars in the passthrough? If yes, can they go on their own line?

That's the default list (which would be superseded by any setting for env_vars), plus the one new one, so this is the minimal perturbation to the build environment. I haven't really given consideration to whether any of the others could be left off for this CI job.

Would it make more sense to add *_NUM_THREADS to the environment variable passthrough in SConstruct? I foresee this as being something that would be useful in other testing scenarios, even locally.

I believe having more thorough tests for multi-threaded operation is an interesting thought. Thus far, it was my impression that multi-threading worked for reactor networks automatically and reliably, which this episode somehow puts in question. That said, I believe the fix for CI is ok as it stands, but it may make sense to address multi-threading in a more strategic fashion in a follow up feature PR.

the env_vars option doesn't support wildcards, so unless you mean listing all of half dozen or more options, not really. There is the option of passing through all environment variables (env_vars=all), but that kind of goes against the SCons philosophy of not passing this information through to keep the build repeatable.

I don't think it would be productive to do any specific testing of multithreaded code that is two layers abstracted from Cantera (with SUNDIALS sitting in the middle, at least in this case), and where we have basically no control over what library the user may ultimately have linked to. I have trouble imagining a scenario in which a problem that arises in such a scenario would be something that could be addressed within Cantera.

the env_vars option doesn't support wildcards

We already do some processing of the env_vars option, though... We could do something like:

import re
import os
r = re.compile(".*_NUM_THREADS")
num_threads = list(filter(r.match, os.environ.keys()))
for n in num_threads:
    # add the options to env_vars

You want to include these variables all the time, not just when they've been specified as part of env_vars? If you want to open a different PR, be my guest.