Although I agree with both of Bruno's reasons, on further thought it makes sense 
for Gnulib to provide a stub instead of an emulation for this particular function.

The primary use for copy_file_range is to copy files more efficiently than a 
read+write loop. However, the read+write loop will typically still be needed 
anyway, to handle non-regular files, copying across file system boundaries, or 
even copying regular input files whose size shrinks while copying as 
copy_file_range (mistakenly, in my view) reports an error if asked to copy past 
end of file.

Because of all these special cases, a reliable use of copy_file_ranges will need 
to be followed by a read+write loop that handles the special cases where 
copy_file_ranges fails. And this read+write loop will work even if 
copy_file_range is a stub that always fails. So there's no practical need to 
emulate copy_file_range.

For an example of the code I'm thinking of, see the call to copy_file_range that 
I recently introduced into GNU Emacs:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=486a81f387bb59b2fbbc6aff7b41adbe1621394e

Because of the above, I simplified Gnulib's implementation of copy_file_range by 
installing the attached. If we find a good use for copy_file_range that could 
take advantage of an emulator rather than a stub, we can revert this.