Well this is a subtle point to do with the way the device (eps2write) works. And although you didn't say so the PDF to EPS conversion has also been done using the eps2write device. Incidentally, you should upgrade, 9.21 is 3 years old.
Note that the EPS file is nothing but a huge image, I assume that the original PDF file contained transparency which resulted in the entire page being rendered to a bitmap at 720 dpi.
When processing the supplied EPS file, initially the clip is set to the size of the media; in the case of your file (using -dEPSCropt) that will be 1740x842.
You then user rectclip to set the clip to be the same path.
The device ignores the initial clip when writing out the contents, so that it does not end up emitting a spurious clip to the output. Because your clip is precisely the same as the initial clip, the device cannot detect it as different, and so ignores it.
In the second case the clip is not the same as the initial clip, so the device actually writes a clip path to the EPS output file.
So all that the rectclip does is add a clip path that clips out part of the image. It won't make the file any smaller.
You haven't said how you are creating the EPS file from the PDF, but it's probably possible to add the rectclip at that point, thereby producing an EPS the size you want and containing the clip you want. Otherwise you can make the rectclip very slightly different to the EPS BoundingBox and it will end up being applied.
Or you can just accept the fact that what you see in Illustrator and Inkscape is actually what's in the file. While the BoundingBox comment tells the importing application how the file is intended to be placed, it is after all nothing more than a comment.
Oh and finally you could render the original PDF file to an image, clipped the way you want, then have ImageMagick, or the image manipulation package of your choice, convert that to an EPS.
EDIT
OK I think you can work around the problem. Because you are producing an EPS file, not a full PostScript program, you don't actually care what the media size is. The eps2write device calculates the BoundingBox, it doesn't use the actual media size at all.
So what you can do is set the media size higher than the BoundingBox, and then apply the clip you actually want. The resulting EPS file will still have the correct BoundingBox comment and will include the clip that you want. It will also have a MediaBox but because this is an EPS file that will never actually be used.
I used this command line:
gswin64c -sDEVICE=eps2write -dDEVICEWIDTHPOINTS="2000" -dDEVICEHEIGHTPOINTS="842" -o "clip.eps" -c "0 0 1740 842 rectclip" -f "out-pdf.eps"
to produce a new EPS file (clip.eps) which incorporates the clip you wanted. Note that the -o switch includes -dBATCH and -dNOPAUSE so you don't need those two switches if you use -o. If you use a recent version of Ghostscript then -dSAFER is not needed either as that is now the default.
I also tried this:
gswin64c -sDEVICE=eps2write -dDEVICEWIDTHPOINTS="1740" -dDEVICEHEIGHTPOINTS="842" -o "clip.eps" -c "0 0 1740 841.9 rectclip" -f "out-pdf.eps"
and that created a EPS file which included a clip, so it does seem like even a small deviation from the initial clip will cause it to be written to the output, as I thought. However, 941.91 did not, so it looks like 0.1 points or thereabouts is the fuzziness.
Of course I'm using the current version (9.53.0) of Ghostscript, earlier versions may behave differently.
