From what I see it goes against the vision of Jenkins Pipeline. If you want to get in UI, Job Restrictions allows doing it in Node configurations. If you need something more, please explain your use-case.

I think the description of this issue needs some more detail, with specific explanation of the problem that currently exists, since it's not obvious.

Use semantic node labels to keep specifics of the Jenkins server/network "implementation" out of the project's build script (Jenkinsfile).  The Jenkinsfile should specify the semantic aspects of what it requires.  For instance, instead of a specific node name, describe the OS required.  Instead of describing a specific version of the OS, describe the features or limitations.

Don't do this: node('mymachine002') { ... }
Don't do this: node('linux002') { ... }
Do this instead: node('linux && amd64 && database') { ... }

Then you can control the specific nodes on which the pipeline will run by assigning appropriate node labels in the Jenkins system configuration.

Perhaps it would be useful to allow configuring per-job parameters/environment variables in to the pipeline script from Jenkins however. This would be a general solution to many problems.

Seems like these are similar

Whether you choose to specify an explicit agent name or a label (as discussed in one of the comments above) is up to you - they work the same way, and we're not going to get rid of that.