Two points: 1) according to acrobat pro your file uses transparency. See this answer for why pdftoeps cannot convert that properly to eps and instead rasterizes it. Since it seems that the figure doesn't really require transparency, but rather some preprocessing step you've done has put everything in a transparency group, you should be able to fix this. 2) rather than ps2eps I would generally prefer epstool. For correcting the bounding box (if it is even necessary, which it shouldn't be here) you can use epstool --copy --bbox filetocorrect.eps correctedfile.eps.
If I'm understanding the situation correctly, you're receiving a document with EPS figures from a customer, and you need to produce bulletproof color and grayscale PDFs which you will then pass on to a third-party to RIP. You may not have control over the software used for the RIP, so you want to do whatever will minimize the probability of problems.
You're using epstopdf to convert the figures to PDF, and epstopdf is simply a wrapper for gs. That means that your current workflow is actually gs+gs+pdflatex. Passing the same figure through gs twice in a row seems like a relatively safe thing to do. If the PDF code generated by gs is buggy, then the bug is presumably present after the first pass, and it's not so likely that any new bug will creep in on the second pass.
The gs+pdflatex+gs workflow sounds like a bad idea to me. I've had problems in the past where filtering pdflatex output through gs produced buggy pdf output, and the result was rejected by a RIP. The RIP was apparently correct to reject it, because the gs output was actually syntactically invalid. The bug was reported to the gs team, who responded by saying that they didn't care and wouldn't fix it: http://bugs.ghostscript.com/show_bug.cgi?id=693322
I would suggest that you do some preflight checking on the figures. It's safest if they use outlines rather than fonts. I've had frequent RIP problems with PDF figures that used transparency, so my current practice is that for any figure that uses transparency, I render it to a bitmap using pdftoppm and have pdflatex grab the bitmap. At 300 dpi they look quite good. Here are a couple of scripts I use to automate that process.
Render an SVG figure to PDF or PNG as appropriate:
http://www.lightandmatter.com/cgi-bin/gitweb.cgi?p=.git;a=blob;f=scripts/render_one_figure.pl
Do a preflight check on a figure:
http://www.lightandmatter.com/cgi-bin/gitweb.cgi?p=.git;a=blob;f=scripts/preflight_one_fig.pl
This is slightly different than what you want to do, since your source format is EPS rather than SVG, but I think you'll find that a lot of the preflight checks and conversion methods will also apply to you. Since we're both on linux, snippets you take from my code should work for you as well.
In general, I don't think pdflatex does any processing at all on PDF figures. It simply copies them into its output. That means that any syntax errors in the PDFs will also be present as syntax errors in the output of pdflatex. It also means that any fonts embedded in the PDFs will be embedded in pdflatex's output. For example, if there is a font in one of the figures whose license forbids redistribution, then that illegal font appears in your pdflatex output as well. It's a good idea to use the linux utility pdffonts on both the figures and the final output so you can see what's going on. For all these reasons, the safest approach of all would be to render every single figure as a bitmap.
Best Answer
ps2pdf -v -should show you the version of Ghostscript (gswin32c.exe). It should be the same asrungs -v(GS used internally by TL).