I personally love this idea and hope a solution can be found. In my mind, there are two main goals here that are closely related (and probably even a bit intertwined/competing):

1) Reduce the number of programs that packagers "assume" is available, and

2) Give RPM maximum latitude to change implementation without breaking anything.

I think that changing the wording to say that RPM will have "capabilities" but not "any specific program to accomplish those capabilities" will satisfy the above goals.

My proposed wording would be something like this:

You may assume that RPM has the ability to function
and process your spec file. This means that RPM is present it can perform
the fundamental tasks (like apply patches, unpack
archives, and run the shell scripts which make up the spec file
sections), but how these tasks are performed (programs/libraries/etc) *cannot* be relied on.
In other words, you should not assume any other packages/programs/libraries are present, as RPM
dependencies and anything brought into the buildroot by the build system
may change over time.