Author's replacement for anchors is to use global syntax, like a top-level "env:" block.

This is a terrible advice from security endpoint - given that env variables are often used for secrets data, you really _don't_ want them to set them at the top level. The secrets should be scoped as narrow as possible!

For example, if you have a few jobs, and some of them need to download some data in first step (which needs a secret), then your choices are (a) copy-paste "env" block 3 times in each step, (b) use the new YAML anchor and (c) set secret at top-level scope. It is pretty clear to me that (c) is the worst idea, security wise - this will make secret available to every step in the workflow, making it much easier for malware to exfiltrate.

I agree. OP’s statement ”the need to template environment variables across a subset of jobs suggests an architectural error in the workflow design” does not ring true for cases where you want developers to be able to quickly deploy a separate environment for each development branch, especially if said branch needs to connect to a matching backend/API/other service.